free(2) doesn't give free -- what ??

[Marcus J. Ranum]

weis at netmbx.UUCP (Dietmar Weis) writes:

>Free(2) frees memory in a running process, but no other process can use it 
>then.

	I assume you mean free(3) - actually, the library routine. malloc
and free manage a memory pool, and request memory as it's needed from
the underlying operating system (using brk/sbrk). Most of the implementations
of free that are out there do not actually return the memory to the system
but instead place it on an internal list where it can be re-allocated in
chunks during subsequent calls to malloc. So, what happens, is that your
process will grow to a steady state but will always be as large as the
largest it got.

>Allocating memory increases the avm column and decreases the fre column.

	This is because the internal pool used by malloc/free will run out
of spare memory, and more gets requested from UNIX, to re-fill the pool.

>Freeing memory decreases avm but does NOT increase fre.

	This is because the memory is placed back into the pool, and is
never returned to UNIX.

>This is fatal I would say, because we have a process which allocates 7 MB
>(don't ask me why) and then frees them later on.

	If you can redesign the process so it doesn't do that, it'd be a
big win. If you can't, you do have the choice of using sbrk to increase
the process size, and brk to shrink it again when you're done. This means
you'd get to re-implement some of the functionality of malloc, which is
decidedly un-fun [though there is a good discussion of an allocator in
K&R V2.0, pp 185-189].

mjr.