whay can't processes shrink as well as grow?

[Brian Chapman]

ggm at brolga.cc.uq.oz.au (George Michaelson) writes:

>My understanding is that existing brk/sbrk/malloc in generic *nix
>doesn't allow the process to shrink again once mem has been allocated.

At the system call level brk() and sbrk() allow you to give the
memory back to the system.  [doesn't it say that on your man page?]

The malloc()/free() stuff implemented on top of that in libc.a has
traditionally never bothered.  Malloc() will brk() for more memory
if it needs it but it free() doesn't brk() the level down if you
give the memory back.  There is no reason for this that I know of
except complexity and execution time trade offs.  (ie. most people
don't care and they don't want free() spending execution time
thinking about it)

>Could somebody explain to a non-wizard what stops some method being
>used to detect free mem pages or compress the heap such that memory
>CAN be freed? I dont mean "for free" ie explain what would have to
>be different in HOW malloc/alloc/sbrk/free work to get this behaviour.

Don't use malloc() and free() just call brk and use the raw address
space you allocate.  This requires an understanding of the process
address space model of your version of Unix.  And is a hell of a lot
less portable than using malloc()/free().  [Well,  OK, I guess it
could be done in a portable way, sort of...]

>I'm expecting to be told that keeping back-pointers to entities using
>allocated memory so you could dynamically update their position if
>you'd compressed the heap is more pain than it's worth. If thats not
>the case, I see some attractive uses of grabbing 5-10 Mb of space, using
>it and then releasing it without having to exit.
>	-George

Yup, malloc() and free() don't work that way, but nothing stops you
from implmenting your own system like you describe above on the system
call brk() sbrk() interface
	-- Chapman
-- 
Brian Chapman		uunet!sco!chapman
Pay no attention to the man behind the curtain!