> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

    > 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 xxxxxx@non-gnu.org 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