> From: Richard Kelsey <xxxxxx@s48.org>

    >    From: Tom Lord <xxxxxx@emf.net>

    >    In short, the FFI requires a root set of unbounded size and
    >    unrestricted locality:

    > Yes, just like Scheme's CONS requires a heap of unbounded
    > size.  No FFI is going to make all programs using it run in
    > all implementations.

How is that "just like CONS" other than the coincidence of the word
"unbounded"?

The issue with CONS is that it can be used to consume all available
memory.

The issue with root set size in the draft is that, far short of
consuming all available memory, it can grow too large for an
incremental collector to handle incrementally -- yet a simple change
to the FFI would eliminate that problem.

In the case of CONS's unboundedness -- we're talking about programs
that _could_not_run_ on the available hardware.  In the case of root
set unboundedness -- we're talking about programs that the FFI will
not permit to run well with some implementations because the FFI
author's had some curious opinions about the aesthetics of C interface
syntax.

    >    The problem goes away if the FFI imposes barriers over GCPROtected
    >    values.

    > It wouldn't take much of a change to do this.  A macro like
    >    SCHEME_SET_GLOBAL(location, value)
    > would do it.  A similar macro would work to support a read
    > barrier, but I believe that those are significantly less common.

Ok, I'll take that as half-a-concession.   Such a change would be an
incremental improvement to the FFI, so to speak :-)

Please additionally consider that:

  ~ I think if you google around long enough for incremental GC
    literature you can find arguments that blacken-on-read is
    better.   I _think_ it was Dijkstra that made this case but
    I'm sorry I don't have the reference handy.   In any event,
    we have many more years of collective experience to gain before
    we can rule out wanting read barriers (whether for incremental
    GC or for some other purpose entirely).   Since it is not
    hard to modify the FFI to not preclude read barriers ....

    (And, incidentally, an example of where you will want a
    read barrier _other_than_ for incremental GC is if you are
    swizzling in objects from a persistent store.)

  ~ More to the point, if you're willing to make that concession we
    should also begin to consider questions of _regularity_ in the
    FFI.  Why a special case for global locations?  Why not make a
    similar macro for locals?

    And: If you eventually come around on passing parameters by
    address rather than value, then why should the assignment
    macros follow a different convention?   If they expect an
    address where you would have them expect an rvalue, that
    will (a) make them more consistent with everything else and
    (b) permit implementations which impose a read barrier.
    If you come around on parameter passing, that is.

-t