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 Wed, 10 Jan 2007 06:14:12 GMT
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.

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

--
> Egor Pasko
>
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

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