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

[Kevin Handy <kth srv net>]

andrew@cogent.ca wrote:
> 
> 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.

One problem that I see with the "each library has it's own caching
malloc
optimizer" is that each library you use will retain the high peak
of memory usage for that library, and not just the total memory
usage for the whole program.

It would be nice to have some type of profile program that will allow
you to tell if the caching code is really accomplishing anything,
and a configure option to let you choose to have the allocation routines
use the raw malloc/free instead of the caching ones.