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:54:03 GMT
On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> It looks like multiple interesting design topics.  My comments inlined
> below.
> 
[..snip..]
> 
> > Hi, I found write barrier in DRLVM can't catch all reference fields
> > updates, and the problem is identified to be caused by new jit opts
> > that do not observe the write barrier invariant for fields updates.
> > For example, JIT may generate code to copy consecutive fields of an
> > object without invoking write barrier. In order to revive the write
> > barrier functionality while not sacrificing the opt performance,
> 
> Yes.  But first how much performance is  being sacrificed?  .2%?  8%??

JIT magic arraycopy gives up to 30% boost on a microbenchmark (see
HARMONY-2247). I did not measure boosts on specific benchmarks, but I
think users would expect System.arraycopy() to be pretty faster than
manual array copying. We should care about performance numbers as
such.

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

-- 
Egor Pasko


Mime
View raw message