Re: tools to make non-conservative GC feasible.

[Greg Harvey <Greg.Harvey@thezone.net>]

"Perry E. Metzger" <perry@piermont.com> writes:

> Jim Blandy writes:
> > This is basically what Emacs does.  I found that we frequently forgot
> > to do the equivalent of s_defGc when it was necessary.  In your
> > example, it's easy to see that rtn->length is protected, since rtn is
> > protected, but when the function is doing something more complicated
> > (walking and editing a tree), it got harder.
> > 
> > Don't get me wrong --- it feels nice and simple to me, too.  But it is
> > a fact that I made a lot of mistakes.  Stallman did too.
> 
> The reason we like "conservative collectors" is because we can be lazy 
> while programming and not worry about what does and doesn't have to be 
> visible to the collector.
> 
> Of course, in fact it is pretty easy to figure out what does and
> doesn't need to be protected -- the problem is that our C compilers
> aren't built to accomodate that.
> 
> Maybe the trick is to build a simple tool that catches mistakes in
> handing things to the collector. I suspect that some hacks to the
> freely redistributable version of lint that comes with NetBSD these
> days could be made to catch places where things weren't explicitly
> handled.
> 
> Anyone have any thoughts?

Instead of building something to find mistakes, we'd be better off
building something to do the work for us. Changing all of guile to use
exact marking would be quite tedious for a human, and if we can figure
out what does and doesn't need to be protected, why not eliminate the
buggy wetware?

The only thing I wonder about is how we insure that an object isn't
gc'd between the time that we unprotect the stack objects and the time
we return it (maybe we could protect all return values?). There seems
to be a way to handle setjmp/longjmp so that the objects remain
protected (elk does it, so I know that it is at least possible, though
I haven't looked at the code much).

-- 
Greg