[gclist] precise access barrier with hardware dirty bits

[Hans Boehm]

On Jul 9, 12:50am, Francois-Rene Rideau wrote:
> Subject: Re: [gclist] precise access barrier with hardware dirty bits
>
> [ plain text
>   Encoded with "quoted-printable" ] :
On Thu, Jul 08, 1999 at 02:12:53PM -0700, Bob Kerns wrote:
> > In extreme cases of small objects and large, non-pagable page map
> > structures, you could not only increase your memory usage by several times,
> > but make most of it non-pagable. It could be cheaper to just keep a copy of
> > the page and find the dirty objects by comparing against the copy! (That
> > doesn't work for read barriers!)
> I believe this technique is actually used by some (Texas?).
> All the more since a copy is often necessary (until flushed)
> for checkpointing purposes anyway, and
> it allows differential compression if you're using a log-based store.
> I feel this technique can be used quite complementarily
> to VMM-based object separation.
>

Note that the diff-based technique isn't correct in all contexts.  There are
situations in which it is unsafe to view a page with the same content as before
as clean.  That can definitely happen (with low probability) in a generational
and/or incremental conservative collector.  I don't know if there are other
such cases.

Consider an object A containing a field X, which can hold either an integer or
pointer (e.g. it's a C union).  Initially it contains the integer B.  If B is
interpreted as an address, it point to someplace outside the heap.

Now the heap is grown, and an object is allocated at address B.  The pointer B
is then assigned to A.X.  (That was the unlikely part.) At the next minor
collection, it is crucial to consider A as modified, so that A.X is scanned and
the object at B is retained, eventhough the diff-based scheme would see A as
clean.  The fact that A was written matters, eventhough its contents didn't
change.

Had A.X not been written at all, we could deduce that A.X is still the integer
B and could not be dereferenced.  Thus we might collect B, but it would be safe
to do so.

Hans


-- 
Hans-J. Boehm
boehm@sgi.com