harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Mon, 08 Jan 2007 01:44:37 GMT
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.

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

Mime
View raw message