Re: More explanation of g_blow_caches / g_debug_shutdown
- From: Owen Taylor <otaylor redhat com>
- To: Michael Meeks <michael ximian com>
- Cc: Tim Janik <timj gtk org>, Gtk Hackers <gtk-devel-list gnome org>
- Subject: Re: More explanation of g_blow_caches / g_debug_shutdown
- Date: 19 Nov 2001 11:47:16 -0500
[ This has been sitting in my outbox since last week; I meant
to send it off before not listing debug_shutdown() in the list
of outstanding API stuff ]
I'd really like to hold off on doing this.
Explaination:
* I think that debug_shutdown() functions do violence to the
code base. It means that widgets (etc,) that should be completely
independent of core code suddenly need hooks into the core.
It's great that Michael has volunteered to do the maintainence
of the ugly code, but sometimes even when you have a volunteer,
it's still not a good idea to introduce ugliness into the
code.
In fact, if we were going to do debug_shutdown() I'd probably
want to see some sort of registration functions rather than
a lot of _gtk_colorsel_debug_shutdown() style functions.
_gtk_colorsel_debug_shutdown() functions also cause problems
for static linking by introducing inter-object dependencies
that aren'tneeded.
But I really don't think we should add some sort of debug-shutdown
registration hook API at this time.
* debug_shutdown() is far from a perfect memory leak detection tool;
it basically has the same problem as doing leak detection with
conservative GC; if you are keeping a block around in a cache somewhere,
you will not treat it as a leak, even if you have allocation growing
without bound.
For memory leak detection, if you can:
- Do conservative GC to detect unreferenced pointers. (Boehm GC,
Debauch, Memprof)
- Diff memory usage profiles between two points in a program.
Then, in my opinion, you will be in a good position to find
almost any memory leak.
I know that quite a few people disagree here and I probably can't
convince them. So perhaps we do need to something in this regard
for GLib/GTK+-2.2; but to the extent _I_ do anything, I'd much
rather spend a bit of time make memprof a really useful tool (by
adding memory usage profile diffing, for example) rather than
spend time registering memory/objects for freeing.
* Finally, doing this work for GDK and GTK+ currently is wasted effort
since much of this will fall out naturally when we do memory management
for multi-head support correctly. If you close a display, then caches for
the display must be freed at that point; while this isn't going to be
_all_ cached memory, it will be a great deal of it, and should be
virtually all objects.
* We just can't add API stuff at this point.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]