1. X does use free (), but the malloc/free system never returns virtual
memory to the OS. It merely increases brk when needed.
2. So it's not exactly a _bug_ though it looks, walks and hogs (virtual)
memory like a bug - it was designed this way.
3. malloc/free were not designed for large, long-lived processes like X.
If you run netscape, which uses a lot of server-side memory, the effect
is easily visible - even if netscape dies and the server calls free (),
process size still remains the same.
4. Xinside's server uses their own version of malloc/free, which actually
unmaps memory which has been freed, once it exceeds a certain limit or
something.
IMHO this sucks badly. Surely malloc/free could check whether there is
a fairly large block between the last allocated chunk and brk ? If
efficiency is the problem then might it be better to have another
function in libmalloc like free_virtual() which can be called explicitly
by those programs which know they need it ?
-- ganesh