[Gc] is this a realistic hope for the gc?
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
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).
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
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
the GSL called malloc it always seemed to get my routines, so maybe
is a legitimate way to use a precompiled GC with an existing library
uses simple memory management, like GSL? I asked how best to use GC
GSL on GSL mailing list, and they advised to use the --wrap linker
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
shared libs use. The implication is that some library authors (even
very high-quality libs like GSL) aren't sure how to use a thing like
3. Gtk. I thought this used threads internally, but now I'm not sure.
I don't know if I myself need any threaded libraries, but its still
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
to use, how to link, and what has to be looked at and done when adding a
library to the list of dependencies for a GC-enabled program or if
who have the experience to do these things without following a specific
could somehow capture their knowledge, I think it would really help to
people use the GC.
Of course, if all of the above is too easy for you guys, there always
of how GC_enable_incremental fits in the whole threaded picture... :)
More information about the Gc