harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Wed, 10 Jan 2007 06:48:19 GMT
On the 0x25A day of Apache Harmony Weldon Washburn wrote:
> On 09 Jan 2007 16:47:52 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> >
> > On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> > > 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.
> >
> > And to the more.. it *is* the current contract in DRLVM
> 
> 
> This is good.  Thanks for confirming this.
> 
> > 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.
> >
> > that is hardly believable. In general, number of pointer updates may
> > vary depending on JIT optimization level (unless we mark all updated
> > fields as 'volatile'.. and we have a free 'volatile'-related test,
> > heh?)
> 
> 
> hmm... I am not sure what is being said.  In any case, we need some sort of
> rigorous WB regression test because a missing WB can cause all sorts of very
> hard to diagnose problems.  Assuming the existing JIT code base has zero WB
> bugs, it is still important to have some way of discovering if future mods
> to the source base cause a WB regression.  Ideally a non-intrusive test
> written in Java would be best.  Of course this may simply not be feasible.

In other words: a Java test is not easy to write so that it checks all
corner cases and FAILs if some small WB does not happen (effect of a
WB very much depends on GC, but we want the test to be JIT-oriented as
much as possible and do not depand on GC, and be non-intruisive, etc.)

Suppose in a Java test JIT does NOT insert a required WB which would
have made no effect in a current GC. So, the test does NOT fail.

The alternative way we can think about is to implement an option in
JIT to dump the number of WBs inserted (in a specific method) and
check it by Java code. My comment was against this approach. The
problem is that in general we cannot count the "right" number of WBs
(the number much depends on the optimization level)

> > 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.
> >
> > Best corner cases can probably be implemented in JIT IR-level test
> > suite (that we were discussing recently). It is currently in JIRA, but
> > can be integrated pretty fast. wbCount verification is natural to
> > implement with the infrastructure.
> 
> 
> Perfect.  Can the above infrastructure be extended to handle all the corner
> cases of WB?

sure. The infrastructure allows to write an IR sample for JIT input
and then verify the correctness of transformations performed by JIT.

-- 
Egor Pasko


Mime
View raw message