This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Tom> If the root set is large, certainly it should be traced in several
> Tom> steps, using barriers to preserve its invariants.
> Is there a practical example of a system that does this? It seems
> very difficult to do, even absent an FFI to C, as your typical root
> set---the current continuation---changes *all the time*. (I'm really
> curious. I could never wrap my mind around this.)
You can treat the "big-three abstract registers" (continuation, code,
and environment) specially. They have usefully limited usage
patterns. It's the other roots, if your implementation has them,
that are of greater interest. (The draft FFI creates "other roots".)
If you want to have a chat about incremental GC strategies, please
c'mon over to the pika-dev@xxxxxxxxxxx mailing list:
http://mail.nongnu.org/mailman/listinfo/pika-dev
Because I want pika to be well suited for Emacs-style applications
(better suited than current Emacs lisp implementations), incremental
GC has been a primary concern in the design. I'd be happy to hash
over the design and get feedback on it.
> In 1997, I developed the prototype for this FFI concurrently with
> hooking RScheme's incremental collector into Scheme 48, so there's
> some evidence that the FFI works with incremental collection in
> principle.
Not all incremental collectors are incompatible with the FFI (a mostly
copying semi-conservative incremental GC would be one example). But
the draft FFI is definately quite hostile to some (reasonable, imo)
incremental techniques.
-t