Re: reclaiming memory guarantees

I don't believe that type 2 memory is *ever* returned to type 1 memory in
real world systems. If you allocate a couple of gigabytes of memory, free
it, and then spend the rest of the life time using only a couple of
gigabytes, your total heap size should stay at 2 gigabytes, even if 99% of
the heap is sitting unused.

Are there any malloc implementations that are actually known to return
memory to the os?

On unix systems, sbrk and brk are used by malloc to manage heap size.
However, my understanding is they can only manage a contiguous heap, i.e.
cannot unmap pages in the middle of the heap, only increment or decrement
the heap size. Because of this, and the fact that C and C++ don't compact
the heap, it's impossible to unmap pages given the interface available.

I suppose this doesn't really matter on systems with virtual memory, since
memory used by a process but not accessed on a regular basis gets swapped
out and only uses harddrive space.

However, especially on a 64 bit system, it should be possible to
accidentally start chewing through harddrive space until you run out by
spawning a number of long running processes that *collectively* only use a
small amount of memory at any given time, but individually use multiple
gigabytes of memory for brief amounts of time (think daemons/servers).
Remember that linux systems typically use a small seperate partition for
swap space. In that case, to save hd space you might actually want to kill
and restart long running processes. This is kind of analogous to the swap
trick, only on a different level.

Maybe I'm wrong about the hd space issue, and there's some vm trick that
prevents long running process' heaps from getting too bloated over time;
however, I can't think of how that would be done.