Re: Garbage Collection questions

[Michael Livshin]

Sam Tregar <address@hidden> writes:

> > do you feel the relevant comments in gc.c are OK as documentation?
> 
> I think they're much better than nothing.  Let me give it a try and I'll
> post the results to guile-devel.  If nothing else it may spur more
> informed people to write some real docs!

thanks!

> > a sufficiently sufficiently intelligent compiler could have a
> > non-contiguous stack and encrypt its contents, too.  we have to make
> > _some_ reasonable assumptions. ;)
> 
> It's interesting you say that.  Perl goes the opposite way - it manages
> it's own stack explicitely and totally ignores the C stack.  The general
> consensus in the Perl dev community is that the C stack isn't something
> you can count on being able to manipulate.  I'd more or less taken that as
> gospel - it's interesting to see the alternate approach working.

I think you are mixing things here.

Guile does not _manipulate_ the C stack in any way.  Guile's
conservative GC scans the C stack to find possible roots.  in order to
feel justified in doing that (i.e. as a rationalization ;), it assumes
that the C stack is always contiguous and non-encrypted.

this assumption has proven to be safe so far, and will likely continue
to be safe, as far as I can see.

now, what you are probably thinking about is why Guile's interpreter
uses the C stack and doesn't manage its own.  this is a totally
different question, and not GC-related at all.

using the C stack in the interpreter buys:

* easy interleaving of C and Scheme frames.

* no special GC logic needed to scan the interpreter stack.

there are alternative designs, though.  the experimental virtual
machine-based interpreter (module guile-vm in the CVS), for instance,
manages its own stack.

in short, I don't think Guile's approach is really "alternative" in
the sense you suggest.

-- 
I'm on a seafood diet -- I see food and I eat it.           -- anonymous