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 Tue, 09 Jan 2007 10:47:52 GMT
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

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

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

-- 
Egor Pasko


Mime
View raw message