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 _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
