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

[Michael Babcock <mbabcock la creatureshop henson com>]

Havoc Pennington wrote:

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

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.

Recent X and Emacs binaries have fixed this.

Netscape may do this too, although it has so many normal memory leaks it
is hard to tell.

I understand the optimization issue perfectly well; I have used it for
certain data structures myself in the past. But the problem is that it
assumes that the process is only running for a short time. If you have a
process that runs for weeks or months it is a big problem, because your
memory usage will always be the maximum of whatever was needed at ANY
TIME in those months. This is especially serious for a server process or
a shared library.

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.

Otherwise glib could do some caching, but needs to do a real free() at
some times so it doesn't literally keep the memory forever. I'm curious,
is the glib memory allocation caching based on a general wrapper to
malloc() or is it done on an individual data structure basis (like list
nodes, etc)?

Perhaps you could define some threshold, say of the number of nodes in
actual use versus the number of already malloced nodes available and
free some when the number of spare nodes get too high. But again,
doesn't modern Linux system malloc already do something like this? I
vaguely remember seeing it when I was looking at the source code.

--
Michael Babcock
Jim Henson's Creature Shop - Los Angeles
mbabcock@la.creatureshop.henson.com