[gclist] write barrier

[Charles Fiterman]

> Unfortunately, this form of mutator-collector communication is
> undesirable in many systems. Let us mention here two problems. First,
> the mutator-collector communication seriously increases the cost of
> every pointer modification performed by the mutator. In fact, the
> communication is more resource-consuming than the actual update of a
> pointer, which amounts to an ordinary memory write. 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. Second, the need to
> have mutator code instrumented makes the mutator-collector
> communication incompatible with existing executable code. In many
> systems, even user code needs to be compiled in a special,
> GC-compatible way.

Its really not that bad. In a non moving collector the collector
doesn't need to be notified of all pointers only all objects. Thus
some pointers may be left uninstrumented. In the C++ wrapped pointer
case this means unwrapped.

A good example is function arguments. If the case usrFunction(new A)
is avoided usrFunction`s parm does not need to be instrumented.
in the call usrFunction(x) whatever x points at is already being
held down by the collector because x is wrapped, wrapping the
parm can be avoided. This can be done in an automated way by a
preprocessor. It is vital in C++ not to wrap function parms because
doing so breaks polymorphism. 

Also return values do not need to be wrapped if it can be guaranteed
that function returns will always land in wrapped pointers. Again
doing this is vital in C++ to protect polymorphism.

There are other cases which are harder to spot. If you have a linked
list and use a pointer to scan it that pointer doesn't need to be
instrumented. The list holds itself together. Wrapping the scan pointer
introduces heavy overhead to no purpose. I don't see an automated way
of spotting this case but doing so by hand is easy.