[gclist] write barrier

[Geert Bosch]

Skubiszewski Marcin wrote about write barriers:

`` [...]First,the mutator-collector communication seriously increases 
   the cost of every pointer modification performed by the mutator. 
   [...] Some overhead remains even while the GC is not running 
   (and thus no actual communication occurs): whenever a pointer is 
   modified, the mutator needs at least to check whether a GC is
   running. ''

Why wouldn't you implement write-barriers using the virtual memory
management units all systems have nowadays? Instead of checking each
pointer-operation, you block pages for writing when the GC is running.
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. This is just a kind of page-fault, although it'll probably
be much faster than a page-fault that requires disk-action.

`` Second, the need to have mutator code instrumented 
   makes the mutator-collector communication incompatible 
   with existing executable code. ''

This is not necessary when using VM techniques. I wonder why you did
not even mention GC systems which exploit VM techniques, since they
are so very valuable in concurrent systems.


  Geert