[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: broken GC
From: |
Rob Browning |
Subject: |
Re: broken GC |
Date: |
15 Aug 2001 11:04:29 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
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
- broken GC, Tom Lord, 2001/08/05
- Re: broken GC, Rob Browning, 2001/08/16
- Re: broken GC, Michael Livshin, 2001/08/16
- Re: broken GC, Miroslav Silovic, 2001/08/17
- Re: broken GC, Michael Livshin, 2001/08/17
- Re: broken GC, Miroslav Silovic, 2001/08/19
- Re: broken GC, Michael Livshin, 2001/08/25