[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: no constants please
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.