Re: Helping on reducing evolution memory usage

[Federico Mena Quintero <federico ximian com>]

On Wed, 2005-12-14 at 19:17 -0500, Morten Welinder wrote:
> > --enable-purify is the one for ORBit at least. Didn't know there was one
> > for glib. What exactly does --enable-gc-friendly=yes do?
> 
> It clears memory held in pools so old pointers does not confuse
> memory debuggers.

The docs
(http://developer.gnome.org/doc/API/2.0/glib/glib-building.html) say
this:

--disable-gc-friendly and --enable-gc-friendly.  When enabled all memory
freed by the application, but retained by GLib for performance reasons
is set to zero, thus making deployed garbage collection or memory
profiling tools detect unlinked memory correctly. This will make GLib
slightly slower and is thus disabled by default. 

This could be more specific:

- When shrinking a GArray, it zeros out the memory no longer available
in the array:  shrink an array from 10 bytes to 7, and the last 3 bytes
will be cleared.  This includes removals of single and multiple
elements.

- When growing a GArray, it clears the new chunk of memory.  Grow an
array from 7 bytes to 10 bytes, and the last 3 bytes will be cleared.

- The above applies to GPtrArray as well.

- When freeing a node from a GHashTable, it first clears the node (which
used to point to the key and the value stored at that node).

- When destroying or removing a GTree node, it clears the node (which
used to point to the value, and the left and right subnodes).

(I've just committed the text above to the documentation.)

In Glib 2.12, this also applied to freeing a GList/GSList node, and to
creating/freeing GMemChunk blocks.  It's a shame that we don't have that
in HEAD.  Which brings us to...

> Note, the glib head has no way of disabling pools.  Before the
> most recen tthings, one could use --disable-mem-pools and be
> happy.

Indeed.  And now, the documentation for --disable-mem-pools is
incorrect, since it does nothing now.

This is all easy to fix, of course, and we need to do it before the
final 2.10.

One thing I absolutely loathe, though, is to have to *recompile glib*
just to be able to run valgrind on GNOME programs.  I'd really prefer to
set G_DEBUG=gc-friendly and just run my software with that.

To avoid calling getenv() all over the place, I'd like to have a private
g_ensure_debug() macro and possibly others to access a global
_g_enable_gc_friendly variable.  This would ensure that we have called
gmessages.c:_g_debug_init(), so that the debug variables are set.

Thoughts?

  Federico