[gclist] write barrier

[Skubiszewski Marcin]

geert@sun3.iaf.nl (Geert Bosch) wrote:

> Why wouldn't you implement write-barriers using the virtual memory
> management units all systems have nowadays?

OK - my text is excessive, I should have mentionned that barriers can
be implemented by faulting, not only by instrumenting code. Please, do
you have biblio references of GCs that use faulting ? I have none.

[...]

> When a the mutator tries to change something on a page which is not
> (completely) scanned yet, the collector can mark it as being changed
> or (better IMO) first scan that page and let the mutator continue
> afterwards.

Scanning the page is possible, but not straightforward. At the time of
the fault, the page typically contains some white objects, and the GC
does not know whether these are reachable or not. The GC cannot
therefore just scan the page entirely. It will scan gray objects
only. For a white object, the scanning cannot be omitted, because the
object may be reachable; it cannot, either, be done in the ordinary
way and result in marking pointed-to objects gray, because the object
is not guaranteed to be reachable.  Scanning a white object must
therefore result in the GC establishing a table which lists all the
pointers to white objects found in this object. If later the object is
found reachable (ie. becomes gray), the objects listed in the table
will also be grayed.

This approach is more complicated that normal three-color marking.
Does anybody use it ?