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: Richard Kelsey <kelsey@xxxxxxx> > From: Tom Lord <lord@xxxxxxx> > 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