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 Richard Kelsey 05 Jan 2004 11:40 UTC

   Date: Sun, 4 Jan 2004 17:16:40 -0800 (PST)
   From: Tom Lord <xxxxxx@emf.net>

   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).

With an incremental collector reading or writing to or from
heap objects may require a read or write barrier.  Reading or
writing root values does not (and cannot - how do you get a
read or write barrier on a machine register?).

   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.

No.  All that is required is that the incremental GC scan the
entire root set in a single increment before deciding that it
has reached the end of a copy cycle.  This is standard practice
for incremental GCs.

SCHEME_CAR() and SCHEME_SET_CAR() and so forth need to preserve
any read or write barriers, of course.

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

I am not sure what 'truly concurrent' means (parallel execution?).
But yes, we chose efficient C execution over allowing the C code
to be interrupted at arbitrary points.
                                            -Richard Kelsey