Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!hub.ucsb.edu!dschub!neptune!slb
From: slb@neptune.dsc.com (Steve Baur)
Newsgroups: comp.unix.internals
Subject: Re: whay can't processes shrink as well as grow?
Summary: *NIX doesn't work that way
Message-ID: <1617@dschub.dsc.com>
Date: 4 Oct 90 11:26:36 GMT
References: <1990Oct3.225943.4691@brolga.cc.uq.oz.au>
Sender: news@dschub.dsc.com
Lines: 63

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

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


The problem has to do with the fact that generic *nix is basically a
swapping system, with virtual memory paging (if it exists at all) added
as an after thought.  This is true through System V/R3.

The UNIX system process data space looks like this:


+-------------------------------+
|       Process Stack           |
|             |                 |
|             V                 |
|                               |
+-------------------------------+
|                               |
|       Free Memory             |
|                               |
+-------------------------------+   <----   "Break"
|                               |
|             ^                 |
|             |                 |
|            Heap               |
|                               |
+-------------------------------+
|                               |
|             BSS               |
|                               |
+-------------------------------+
|                               |
|            Data               |
|                               |
+-------------------------------+


The line above the heap (called the "break") is adjusted via the brk(2) and
sbrk(2) system calls and is adjusted upwards when more memory is needed.
It could also be adjusted downwards when allocated memory just below the
break is released, but that does not seem to be performed through System
V/R3.

A more basic problem exists with this scheme though.  Imagine allocating
a 100k chunk of memory, then a 10 byte chunk of data, then deallocating the
100k chunk.  Now the allocated 10 byte chunk of data sits just below the
break, and hence it cannot be adjusted downwards to reflect the release
of the 100k chunk.  No holes are allowed to exist between the top of BSS
and the break.

Anyway, to properly deal with a paging system, something like a getvmpage/
releasevmpage (that treats virtual memory as pages rather than as an
area below an address) is needed.

--
"The speed of light ...  It's not just a good idea, it's the law."
Steve Baur (slb%neptune%dschub@hub.ucsb.edu)