larryh@tekgvs.GVS.TEK.COM (Larry Hutchinson) (09/23/88)
It appears that the MPW C library routine, sscanf, creates and leaves behind a locked handle to 0xc8 bytes the first time it runs. This can cause heap fragmentation if it happens at a bad time. My workaround is to do a dummy call at initalization time to force the handle into the low heap area along with all the other non-relocatable objects. This brings up a few questions about memory management: (1) Does anyone happen to have a routine that one could put in the event loop that would check the heap for general health? It is a pain (and very time consuming) to keep poping into TMON to scan the heap looking for fragmentation and other such problems. (2) How smart is the memory manager? When I found the above mis-feature, I had the following heap situation: low heap: . . free space locked handle from sscanf huge scarf handle misc smallish handles free space . high heap: . The scarf handle is used to artifically create a low memory situation. I had quite a bit of free memory and was trying to increase the size of the scarf handle to decrease the free memory. Even though I was only trying to 'SetHandleSize' the scarf handle to 2 more bytes than it already had (about 1.2Mb), the memory manager would have none of it. Clearly the small handle just above the scarf handle could have been moved out of the way. Question: is this normal or anomalous behavior? (3) How much free memory is required to get reasonable performance out of the memory manager? Is it best to run with a large grow zone kludge buffer and let the free memory approach zero or is it best to run with a smaller kludge buffer but enforce a relatively large amout of free memory? My observations indicate the 2nd option is better. Have a Day. Larry Hutchinson, Tektronix, Inc. PO Box 500, MS 50-383, Beaverton, OR 97077 UUCP: [uunet|ucbvax|decvax|hplabs]!tektronix!tekgvs!larryh ARPA: larryh%tekgvs.TEK.COM@RELAY.CS.NET CSNet: larryh@tekgvs.TEK.COM