Re: my ongoing fantasy of garbage collected C programming

[Mark Mielke <mark mark mielke cc>]

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

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

Cheers,
mark

--
Mark Mielke <mark mielke cc>