harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Mon, 08 Jan 2007 04:45:36 GMT
On 1/7/07, Robin Garner <robin.garner@anu.edu.au> wrote:
>
> 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.


I like it.  Its concise and as far as I know, accurate.  Moving to
substituting write barriers exclusively is very attractive now that vmmagic
is supported in drlvm.  Given that we still have old pre-vmmagic GCs laying
around, we need to support non-substituting WBs for a little while longer.

One thing we need to build are regression tests that demonstrate with
(hopefully) high accuracy that the JIT is correctly emitting all the WB
corner cases.  The hope is that it is possible to build these regression
tests entirely in app Java.  This would make these tests non-intrusive which
is very desirable.  The other approach is to instrument the JVM snap all the
WB writes.  The idea is to write some simple Java code, then manuallly count
all the ref ptr assignment locations.  Then verify that wbCount == the
manually counted writes.

> 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
> http://cs.anu.edu.au/people/Robin.Garner/
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message