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.
Date: Sun, 4 Jan 2004 17:16:40 -0800 (PST) From: Tom Lord <lord@xxxxxxx> 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