whay can't processes shrink as well as grow?

[Conor P. Cahill]

In article <1990Oct3.225943.4691 at brolga.cc.uq.oz.au> 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.

True.

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

Nothing stops this from being implemented and it would not require a 
change to the way free() is *allowed* to work.  However, some programs
depend upon an old free() behavior that says something to the effect that
the free'd segment is still available until the next call to one of the
allocation functions.

Besides that "compatibility" reason, you have to consider the usefulness of 
that kind of change for the "average" program.  What I mean here is what 
measurable effect would adding that functionality have to the system as 
a whole?  If it is not measurable (like being able to support x% more
users with the same amount of memory, or a x% increase in overall system
performance) then why do it?

Even though free does not actually return the memory to the system, it
does mark it for re-use, so your programs do not grow indefinately (unless,
of course, you have a bug in your program).

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

Heap compression is a different animal all together.  You would run into
zillions of problems with programs that got the pointer returned from
malloc and copied it elsewhere, etc.  To allow for this you would have
to require that any access to a malloced area be made through one of your
functions that would then do the translation to a real address (sort of
your own virtual memory manager).  talk about a bad effect on performance.

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

You could probably do with other mechanisms that do not require the jump 
to 10MB of mem and the fall back to 0, or that use a child program to 
process the 10MB of data and passes it's output back to the parent and
exits (thereby freeing the allocated memory).


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170