[Mono-devel-list] Garbage Collection problem

[Michael Poole]

Jonathan Pryor <jonpryor at vt.edu> writes:

> This is just a guess, but I don't think this is easily solvable.
>
> Unix platforms use sbrk(2) to allocate additional memory from the
> Operating System.  I don't know of any mechanism to *release* the
> allocated memory back to the OS.
>
> Once memory is allocated for a process, there is no way (that I know of)
> to release it.
>
> Thus, even after a garbage collection, the GC heap may be fully
> collected, even empty (i.e. containing no user-allocated objects), but
> without a means for the OS to reclaim space, the actual memory used
> *cannot* decrease.
>
> Please correct me if I'm wrong.

On Linux, rather than use sbrk(), you can anonymously mmap pages from
/dev/zero to allocate pages at arbitrary locations.  When you are done
with them, you can unmap them and the pages go away.  It becomes
inefficient if you operate at places other than the end of your
allocate space, since the kernel needs to create a new VM region.

glibc 2.x on Linux does mmap /dev/zero for allocations; I do not know
if it ever releases that memory.  Some apps (thankfully including
XEmacs) take steps to make sure unused memory is given back to the
kernel.

I imagine that other recent Unix-like OSes have similar mechanisms,
but I have no first-hand knowledge of them.

Michael Poole