harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Garner" <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Tue, 09 Jan 2007 15:05:52 GMT
> On the 0x257 day of Apache Harmony 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.
> That's what I think we should do. I see it like this:
> * JIT asks GC if it has_object_update_wb_feature()
> * JIT checks CompilationInterface.insertWriteBarriers()
> * if both true, JIT inserts code that update whole objects with a
>   single "object/array update barrier". If only second is true,
>   generate an ordinary code.
> * "object update barrier" should NOT be a GC safe point
> The scheme is not complicated and easy to implement in JIT. Just need
> to put the right checks in right places. It should not be difficult to
> implement the feature in GCv5, isn't it?
> In spite of introducng more state-dependant code, I think, the feature
> is worth it from performance point of view.

This is what JikesRVM does, and yes, for some (macro) benchmarks it pays off.

>> 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
>> >
> --
> Egor Pasko

View raw message