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

[Joe Pfeiffer <pfeiffer cs nmsu edu>]

	> 
	> 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.

I don't really see that this is much of a problem.  Yes, it's got all
that VM in your process space, but if it's unused you're not using up
any physical memory with it.  Big swap spaces on disk are cheap.

   [...]
	> 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.

I don't see any of this as being the point -- it seems like a good
idea to be able to fall back on the system malloc/free so that it's
easier to inspect user programs for memory leaks using standard tools.
-- 
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer