Re: Helping on reducing evolution memory usage

[Tim Janik <timj imendio com>]

On Wed, 14 Dec 2005, Federico Mena Quintero wrote:

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

hrmm. i think zero-ing upon growing an array should either be done
always or never, but not depend on gc-friendlyness. (it's essentially
a bug if a user requests bigger arrays and uses them without intialization,
and shouldn't be covered by gc-friendlyness).

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

thanks.

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

well, if you refer to gslice here, i'm simply not done with fine
tuning it yet. i could have waited with the final commit until i 
consider everything set and done, but then it'd have missed out
the importing testing/debugging/profiling phase it's currently
going through, and it'd probably have taken forever ;)

my initial announcement:
  http://mail.gnome.org/archives/gtk-devel-list/2005-December/msg00031.html
even has a list of these remaining TODOs, everyone's free
to help here, especially with profiling.


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

sure, we're even taking patches from the not-so-patient people ;)

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

this'd be mighty cool. i'm not sure matthias or i have the time to go 
over glib and implement this though, but if someone provided a patch,
he'll get feedback and we can most probably have that for the next
major release.

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

i've recently had to hack the order in which we intialize stuff.
for g_mem_gc_friendly (that's the namespace i'd put it in), you actually
want an internal initialization function that is called from gmem.c (here
a hook will have to ba added to all g_*alloc() variants) and gslice.c
(there's g_slice_init_nomessage() already) on demand.
that'll ensure it's setup before any allocations can be made.

> Thoughts?
>
>  Federico

---
ciaoTJ