Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!apple!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Heap Fragmentation
Message-ID: <11161@smoke.BRL.MIL>
Date: 28 Sep 89 02:18:55 GMT
References: <1989Sep27.045926.12634@polyslo.CalPoly.EDU> <35076@apple.Apple.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33

In article <35076@apple.Apple.COM> mikes@Apple.COM (Mike Shannon) writes:
>In article <1989Sep27.045926.12634@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes:
>>Is heap fragmentation in C a problem or non-problem?
>Memory management is not part of the C language, it is part of the library
>support in the underlying system.

The modern point of view is that there is no crisp distinction between
the language and the run-time support.  In a hosted implementation, the
forthcoming Standard requires that malloc()/realloc()/free() be supplied.
They could be implemented as language keywords (actually, as macros
defined in terms of reserved-name keywords) as well as library routines.

>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.
In other contexts, for example in the Apple IIGS/Macintosh desktop
environment, it is desirable for memory no longer in use by active
processes to be immediately returned to the system resource pool.

>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.

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.