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
