Re: no constants please Richard Kelsey (04 Jan 2004 18:11 UTC)
Re: no constants please felix (04 Jan 2004 19:25 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 20:08 UTC)
Re: no constants please Tom Lord (04 Jan 2004 21:13 UTC)
Re: no constants please Tom Lord (04 Jan 2004 21:43 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 22:59 UTC)
Re: no constants please Tom Lord (05 Jan 2004 00:50 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:19 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 11:42 UTC)
Re: no constants please Tom Lord (05 Jan 2004 16:26 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 17:49 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:24 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 18:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 22:00 UTC)
Re: no constants please Michael Sperber (06 Jan 2004 07:42 UTC)
I don't believe in "(may GC)" Tom Lord (05 Jan 2004 00:55 UTC)
Re: I don't believe in "(may GC)" Richard Kelsey (05 Jan 2004 12:07 UTC)
Re: I don't believe in "(may GC)" Shiro Kawai (05 Jan 2004 12:45 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 18:16 UTC)
Re: I don't believe in "(may GC)" Tom Lord (05 Jan 2004 16:35 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 17:54 UTC)
Re: I don't believe in "(may GC)" tb@xxxxxx (06 Jan 2004 01:39 UTC)
Re: I don't believe in "(may GC)" Michael Sperber (06 Jan 2004 07:39 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:05 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:12 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 12:17 UTC)
Re: no constants please Tom Lord (05 Jan 2004 17:40 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 19:03 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 01:37 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 02:15 UTC)
Re: no constants please Tom Lord (06 Jan 2004 02:29 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 02:31 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 03:10 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 03:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 04:06 UTC)

Re: no constants please Tom Lord 05 Jan 2004 01:16 UTC


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

    >    But the problems with the current FFI include issues with
    >    single-threaded, no-async-issue Scheme implementations including:

    >    ~ don't handle read/write barriers properly
    >    ~ don't handle transient root set members properly

    > You haven't convinced me on these points.  You have given examples
    > of misuses of the FFI, in which values are left in unprotected
    > locations during a call to a possibly-GCing procedure.

Sorry for the confusion.  I did indeed miss that the SRFI requires:

	Note that the C function, if it allocates Scheme heap storage,
	must register its parameters with the garbage collector.

which undermines the specific examples I gave.   Here is an example
of a read/write barrier problem that I believe is based on code that
is "correct" under the draft specification:

	{
          SCHEME_DECLARE_GC_PROTECT(2);
          scheme_value x = SCHEME_UNSPECIFIC;
          scheme_value y = SCHEME_UNSPECIFIC;

          SCHEME_GC_PROTECT_2 (x, y);

          [.... set y to some heap-allocated value ....];

          [.... do some possibly-GC-causing stuff ....];

          /*A*/

          x = y;

          [.... do some possibly-GC-causing stuff ....];

          /*B*/

          SCHEME_<any> (x);

          SCHEME_GC_UNPROTECT ();
        }

The error occurs in an incremental copying collector which believes
at point /*A*/ that it has updated `x' but not yet 'y' and at point
/*B*/ that it has reached the end of a copy cycle.

The old (pre-copying) reference to the value of `y' has been copied to
`x' -- too late for `x' to be updated.   When `SCHEME_<any>' is
called, it is passed a bogus value.

Reading or writing to or from root values (or any other Scheme
location) in an incremental, copying collector requires a read or
write barrier in order to preserve the tri-color invarient -- but the
naked C assignment `x = y' affords no such barrier (hence, permits the
invariant to be violated).

In order to preserve the invariant in the face of C's assignment
operator, at least all GC_PROTECT_GLOBAL locations and all GC_PROTECT
automatic variables must be, whenever such an assignment is possible,
the same color.   Unless the draft is modified to prohibit assignments
of the form `x = *z' where `z' is a `scheme_value *' that may point to
a GCPROtected automatic in some caller's frame -- then _all_
GCPROtected locations must be of the same GC color whenever a foreign
function is executing code between GC points.

Either way, the FFI is basically incompatible with incremental garbage
collection.

A "philosophical" way to look at this might be:  with
SCHEME_DECLARE_GC_PROTECT and SCHEME_GC_PROTECT_<n> and
SCHEME_GC_PROTECT_GLOBAL you are letting FFI-using code extend the
Scheme heap, extend the GC's working storage, _and_ giving the C
compiler license to read and write the Scheme heap directly.  In
fairness, you're trying hard to limit what the C compiler can do while
reading and writing the Scheme heap by taking advantage of sequence
points and declaring that some legal C code over these types is an
illegal use -- but examples like the above show that those limitations
are insufficient.

In contrast, with Pika-style conventions, you are letting FFI-using
code extend the Scheme heap, extend the GC's working storage -- but
_not_ giving the C compiler license to read and write the scheme heap
at all, nor sanctioning any FFI-using C code which does so.

Given the kinds of restrictions you are imposing on what counts as
correct FFI-using code, plus the restriction that parameters must be
GCPROtected in functions that may cause GC, I have serious doubts that
Pika-conventions have any real overhead compared to what you are
envisioning.  The number of stores and loads comes out the same
(Pika might even come out ahead).  Pika is simply less error
prone and more general.

-t

(You also talk about threads and interruption points related to them
but, of course, that doesn't address truly concurrent threads.)