Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!uwm.edu!uwvax!umn-d-ub!nic.MR.NET!thor.acc.stolaf.edu!mike From: mike@thor.acc.stolaf.edu (Mike Haertel) Newsgroups: comp.lang.c Subject: Re: Heap Fragmentation Message-ID: <6643@thor.acc.stolaf.edu> Date: 28 Sep 89 16:55:05 GMT References: <1989Sep27.045926.12634@polyslo.CalPoly.EDU> <35076@apple.Apple.COM> <11161@smoke.BRL.MIL> Reply-To: mike@thor.stolaf.edu () Organization: St. Olaf College, Northfield, MN Lines: 45 In article <11161@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <35076@apple.Apple.COM> mikes@Apple.COM (Mike Shannon) writes: >>It's my understanding that de-allocated memory chunks are never handed >>back to the operating system, ... > >In a UNIX context, traditionally applications have mixed sbrk() calls >with (perhaps implicit) use of malloc(), so it would be unsafe for >a UNIX malloc()/free() implementation to shrink the heap in general. Not true. GNU malloc(), of which I am the author, can shrink the heap. (This is a new and different malloc(), distinct from the ancient Caltech malloc() we have previously distributed.) Callers can freely mix sbrk() calls. The algorithm is: if (sbrk(0) == mallocs_notion_of_top_of_heap) sbrk(negative_amount); >>In summary, I would say heap fragementation under UNIX is not a problem. > >It can be, but unless you're pushing the limits on maximum virtual >data space size it would take a rather unusual memory allocator usage >pattern. If you want to be absolutely sure of avoiding heap fragmentation, don't trust any allocator (even mine :-) and write a dedicated allocator as a front end to malloc(), that malloc()s huge and parcels them out as needed, and later free()s them in a batch when appropriate. The GNU obstack macros implement one such allocation discipline. >Garbage-collecting equivalents of malloc()/free() have been devised >from time to time. Rob Pike's Blit terminal (and descendants) >firmware relies very heavily on one, and Rob's "sam" text editor >uses a similar scheme. If memory is a critical resource (as it is >for the terminals), a garbage-collecting allocator may be worthwhile. Yes. If you know the types and roots of all your data structures, this is straightforward. Even if you don't you can write a (nonportable) "conservative" garbage collector that scans all variables, heap, stack, and registers looking for possible references. Empirically such conservative allocators have been observed to do a reasonably good job of reclaiming dead storage. -- Mike Haertel``There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself.'' -- J. S. Bach