Re: my ongoing fantasy of garbage collected C programming

Tim Janik wrote:
AFAIK, no one has tried to make boehm GC really work with glib & gtk+
programs so far. The "gc friendly" mode that glib has in general just
zeros-out certain memory portions before calling free(), so GC-alike
leak detectors like e.g. valgrind can do a more accurate job.

Depending on how clever your GC implementation is, I'd actually expect
quite some real world problems with it trying to "collect" glib
memory. E.g. GLib only stores pointers into the _middle_ of fundamental
GType nodes (not the node start) and with GSlice provides its own
allocator that cannot be replaced with GC collection (the memory pages
allocated by gslice.c:allocator_memalign are also not pointed to
directly, a pointer to an admin structure at the page tail is kept

A conservative collector that makes no assumptions about where the pointers are (I believe this is the default Boehm GC mode?) will not have any problem with the above.

I foresee limited benefit of GC for Gtk+/Glib at this time, as many of the data structures are reference counted today, and reference counting PLUS garbage collection is certainly slower than reference counting alone... :-)


Mark Mielke <mark mielke cc>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]