What's an object remembering barrier?
On Jan 7, 2007, at 1:59 AM, Robin Garner wrote:
I disagree. Partly from the point of view of eventual support for
MMTk,
but also on more general grounds, in terms of support for future GC
algorithms.
If the memory manager requires that the compiler invoke the write
barrier
for each pointer store, then it should honour the contract and do so.
If you want to provide an object remembering barrier that the
compiler can
call as an optimization, then by all means do so, but the GC should
not be
forced to work around compiler 'optimizations' that break fundamental
interface contracts.
While object remembering barriers may be adequate for GCV5 there are a
large family of GC algorithms that they are inadequate for, including
reference counting and concurrent/incremental GCs.
regards,
Robin
Hi, I found write barrier in DRLVM can't catch all reference fields
updates, and the problem is identified to be caused by new jit opts
that do not observe the write barrier invariant for fields updates.
For example, JIT may generate code to copy consecutive fields of an
object without invoking write barrier. In order to revive the write
barrier functionality while not sacrificing the opt performance, I'd
suggest to introduce an object remember write barrier which will be
invoked after the object is copied. So the JIT doesn't need to insert
barrier for each field store. GC has an interface
gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
only the runtime native call at first. Then later we can consider to
inline the object remembering barrier as well as the slot remembering
barrier.
Thanks,
xiaofeng
