Re: broken GC

[Miroslav Silovic]

Rob Browning <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
> 
> > But I think it is still a big selling point of Guile that you don't
> > have to put your own GC hints into the code for automatic variables.
> 
> Well my first reaction to this was to agree, but I have to say that
> after considering what Tom has said and thinking about it for a bit,
> I'm not so sure.
> 
> Frankly, I tend to think that no matter what, if you're going to write
> C code that plays nice with Guile, you're going to have to follow some
> rules.  As long as those rules are *well documented*, then I don't
> think it's such a big deal.  In fact, I wonder if a guile with a
> precise GC and *really* good docs for how deal with it might not be
> easier than a guile with a conservative GC and weaker docs.
> 
> First though, I think it would be worth discussing exactly what would
> be required of the C extension coder given a precise GC, so we can
> accurately evaluate whether this would be an undue burden.  After
> that, if we decide that a precise GC is better, then I think we should
> just get on with it -- make an announcement, plan a major version
> number change, and do what we can to make the transition easier
> (tools, whatever).

There is something to be said about the rules required to write an
application that works well with precise GC. In particular, precise GC
is much, *MUCH* worse to work with than even refcounting: while it's
equally easy to forget to (un)protect an object with precise GC as it
is to insert the the proper (un)ref calls, the effects of such
ommisions are far less deterministic... i.e. your program will crash,
maybe, eventually, in some cases. On the other hand, it's almost
trivial to document the rules required to work well with conservative
GC:

 - don't put SCM refs into the static variables
 - don't build infinite datastructures reachable from any single cell

The latter rule prevents memory leaks - as you don't know that GC will
release any particular cell. For example, you should implement FIFO
using cons cells by letting the unused cells still point to the live
ones: as any unused cell can be conservatively pinpointed, all the
newly created cells may float unreclaimed. But then, there are other
ways to implement a FIFO.

Despite this limitation, I frankly think that precise GC would make
Guile not worth the bother for C apps (C++ smart pointers might help
C++ code to play nice). I recall somebody saying that precise GC was
the main source of pain for Emacs programmers (but then, not being an
Emacs hacker, I wouldn't know).

-- 
How to eff the ineffable?