harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Sun, 07 Jan 2007 21:40:01 GMT
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

View raw message