[gtk-list] Re: how can I trust glib when it has so many mem leaks?

[andrew cogent ca]

Michael Babcock writes:
 > > They aren't really leaks in glib, glib just keeps chunks of memory around
 > > and recycles them. This makes it run a lot faster. The memory is never
 > > released to the operating system, just back to glib. So you should just
 > > ignore everything ccmalloc and friends report for glib.
 > 
 > Arrrgh! I hate it when programs do this! X used to do this and it was
 > extremely annoying. You had to restart your X server every so often
 > because its memory usage would just grow and grow and never shrink. If
 > you ran a graphically intense program that made X allocate a lot of
 > pixmaps and your X server grew to 30 MB, then, that was it, it stays at
 > 30 MB till the end of time (or until you restart the X server). I think
 > Emacs used to do this as well.
[...]
 > We need a way to disable this and tell glib to use the normal system
 > malloc and free. I'd also be interested in some benchmarks about how
 > much of a difference this makes for real gtk programs. I didn't notice
 > any big difference in speed when my X and Emacs binaries were changed to
 > use the system malloc. The latest malloc in glibc is actually pretty
 > efficient and I think already does some sort of pooling itself.

Most operating systems that I have used do not implement a malloc/free
combination that will shrink the process data space on a free() call.
The system malloc would in fact cause your process to reach a *higher*
high water mark and stay there, because of both (potential) free list
fragmentation and the header overhead associated with each allocated
chunk.

So, in general, free() gives you nothing in this instance.  There may
be specific implementations on specific architectures that can give
back free()d memory to the OS before the process terminates, but that
is not generally true.  In addition, you could have a huge amount of
free memory that is not at the end of your process address space, and
still not be able to give it back, even if your malloc/free routines
did normally allow it.  This is a side effect of the memory
fragmentation that that the glib allocation routines are trying to
avoid, but that free() will not.  In the good old days, some C library
calls bypassed malloc altogether and used sbrk() to allocate a little
bit of memory.  If your clib implements any call to sbrk() outside of
the malloc/free routines, you cannot safely shrink your process data
space, and you lose anyway.

Andrew