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 Mon, 08 Jan 2007 03:47:39 GMT
Xiao-Feng Li wrote:
> On 1/8/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
>> > 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.
>> hmm.... what happens if some other app thread causes a GC to happen in 
>> the
>> middle of writing a bunch of fields of a given object?  If the
>> gc_heap_wrote_object() is called before JITed code scribbles on slots, 
>> then
>> the early slots will be scanned and handled properly by the GC.   But 
>> how do
>> we handle the slots written after the GC completes?  One approach 
>> would be
>> for the JIT to mark such regions of emitted code "Uninterruptable".
>> Another approach would be to emit a WB both before and after a region of
>> multiple ref field scribbles.   In any case, it looks like we need 
>> patch up
>> the holes in the contract between jit and gc.  However, as I said 
>> above is
>> there anything wrong with a real simple dumb contract for now?  That 
>> is each
>> ref write has a matching WB with no intervening instructions.
> Why can that be an issue? GC can only happen at safepoint, it can't
> happen in the middle of object copy. Object copy exists no matter
> there is write barrier or not.

I think this is the specification of the contract (if DRLVM persists 
with non-substituting write-barriers): no GC safe point can occur 
between the write of a field and write-barrier completion.  Within a 
basic block (or a chunk of @Uninterrubtible code) , the compiler can do 
whatever instruction scheduling it likes.

> Thanks,
> xiaofeng
>> >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
>> >

>> -- 
>> Weldon Washburn
>> Intel Enterprise Solutions Software Division

Robin Garner
Dept. of Computer Science
Australian National University

View raw message