Re: broken GC

[Rob Browning]

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

> Maybe this point is not so big if you look at it closely since you
> still have to understand what is happening and take care that the
> compiler doesn't hide important SCM values from the eye of the GC.

Exactly.  I tend to think that it might in some ways actually be
*better* than the current situation since everything would be more
explicit.

> Still we must consider the huge API change for the user when we go
> the gcpro route, i.e., requiring the user to put in the GC hints
> manually.  I don't think we can do that without causing a major out
> cry.

Maybe, but I can tell you that if there were obvious benefits, and it
was the "RIGHT THING(TM)", at least those of us working on gnucash
would be fine with the change.

> I think it would be acceptable to require a preprocessing pass that
> rewrites the C source into one that contains the needed hints.  That
> pass could be quite involved, using code from GCC or your cparse.
> 
> It would at minimum recognize local variables of type SCM and put in
> some (conservative?) protection code.  It could also help with telling
> the GC about SCM values in structs that need protecting, etc.
> 
> The generated code could be system dependent so we could use
> hypothetic special features of GCC, say, like a static description of
> the stack layout that is keyed on the PC.

This sounds like a *very* interesting idea, and one with the potential
to allow some very clever tricks later, but we'd need to be careful to
balance the benefits against the maintenance cost.

Though as I said, I think the first thing would be to consider how
hard, given really good documentation (and maybe some simpler tools),
it would be for a coder to handle things by hand...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD