[Gc] is this a realistic hope for the gc?

Britton Kerin bkerin at fastmail.fm
Thu Jul 17 18:46:41 PDT 2008


I'm trying to figure out a policy for how to use GC in the real
world, with libraries.

Sorry if this is too many posts.  The prospect of having a GC for C
just gets me so excited and hopeful.  Looking through the code at
the various comments on thread-related matters I'm not sure if it
will quite work for me though, or if there might exist some 
discipline I could follow that would let it mostly work.

I think others probably have some of the same uncertainties I do
on this one, and if anyone can help I'll prepare some sort of
document explaining as best I can how things work.

The dream of course it to be able to use whatever precompiled
libraries one wants, with as many threads as the heart desires and never
worry
about garbage collection, nor have the collector cause unseemly
hiccups while doing full collection cycles.  How achievable is
this in general?  I think my situation presents an interesting
coverage of the possible library issues one might have:

1.  glib -- has the set_vtable fctn, and also these days
    --enable-gc-friendly, --enable-debug=yes, and two
    significant environment vars that control run-time
    behavior: G_DEBUG=gc-friendly and G_SLICE=always-malloc

For this one, the gc seems to work (i.e. doesn't seg fault in a
GC_malloc) for the program I'm working on if either:

a. G_DEBUG=gc-friendly and G_SLICE=always-malloc are set at run
   time (set_vtable alone doesn't do it).

  or

b. gc is compiled with --enable-redirect-malloc (but then the GC
   does make things many times slower when threads are also
   enabled, as the docs warn.

2. the GNU Scientific Library (GSL).  This library doesn't have support
   for set_vtable like functionality, but it appears to use plain old
   malloc internally and no fancy slice style stuff like glib.  For a
   library
   like this, is --enable-malloc-redirects the only way?  I tried just
   putting my own malloc free etc. that called GC_* in my program, and
   when
   the GSL called malloc it always seemed to get my routines, so maybe
   this
   is a legitimate way to use a precompiled GC with an existing library
   that
   uses simple memory management, like GSL?  I asked how best to use GC
   with
   GSL on GSL mailing list, and they advised to use the --wrap linker
   option.
   I'm not convinced this works though: I still seem to end up in system
   malloc from gsl_* fctns according to debugger.  It seems like it only
   affects the program being linked, and not the fctns that already
   linked
   shared libs use.  The implication is that some library authors (even
   of
   very high-quality libs like GSL) aren't sure how to use a thing like
   GC
   themselves.

3. Gtk.  I thought this used threads internally, but now I'm not sure. 
So
   I don't know if I myself need any threaded libraries, but its still
   an
   interesting question: what are the implications of a threaded library
   for how gc must be used?

As I said at the start, if there is an approach to which type of gc
build
to use, how to link, and what has to be looked at and done when adding a
new
library to the list of dependencies for a GC-enabled program or if
people
who have the experience to do these things without following a specific
policy
could somehow capture their knowledge, I think it would really help to
let more
people use the GC.

Of course, if all of the above is too easy for you guys, there always
the question
of how GC_enable_incremental fits in the whole threaded picture... :)

Thanks,
Britton




More information about the Gc mailing list