[gclist] write barrier

[Nick Barnes]

> "A write barrier is a mechanism for executing some memory management
> code when a write to some object takes place ..."
> 
> I would propose to generalize this a bit.  It's a mechanism for
> performing some action in response to every write operation in a
> certain memory region.

Well, I'd be picky with that. Firstly, "region" to me implies
contiguity, but I like to think of a single barrier, regardless of how
many non-contiguous regions of memory (pages, whatever) are
protected. And secondly, when you have inlined barrier code, the
barrier might only be present for certain sorts of writes to certain
sorts of objects (e.g. the compiler may distinguish certain writes --
e.g. non-pointer writes -- as not requiring a barrier). So, for
instance, in SML:

	datatype foo = A | B of int list

	val fooref = ref A		(* a writable value *)

	(fooref := B [1,2,3,4])		(* this may have memory barrier code *)
	(fooref := A)			(* this need not *)

> I would classify our collector as write-barrier-based.  But the only
> action that needs to be performed on a write is to keep track of the
> fact that the page in question is now dirty.  Under an operating
> system like Solaris, that bookkeeping is all done within the VM part
> of the kernel; the garbage collector doesn't get notified.  (For
> Solaris on X86, it presumably all happens in hardware.)

It's still a memory management action. How about:

"A write barrier is a mechanism for performing some memory management
action when some forms of memory write take place".

> The same is presumably true of any other VM-based incremental update
> collectors.

Not necessarily. For instance, a VM-based system may choose to grey a
white page at the time of a white-on-black write.

Nick