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 Mon, 08 Jan 2007 00:49:17 GMT
It looks like multiple interesting design topics.  My comments inlined

On 1/6/07, Robin Garner <robin.garner@anu.edu.au> wrote:
> I disagree.  Partly from the point of view of eventual support for MMTk,
> but also on more general grounds, in terms of support for future GC
> algorithms.
> If the memory manager requires that the compiler invoke the write barrier
> for each pointer store, then it should honour the contract and do so.

Good point.  I don't recall the contract specifically stating each write to
an object slot requires a call to the write barrier.  It must have fallen
through the cracks.  It seems we should create a clearer contract.  On a
related note, should DRLVM gc/vm contract say that only substituting write
barriers are allowed?  The reason I mention this is because if the JIT is
allowed to call the write barrier as a seperate operation from doing the
actual writes, then we probably have to specifiy if the write barrier has to
happen before/after the actual write.  A real messy one would be specifying
the distance between a write and its write barrier.  Is it OK for the JIT to
lazily generate a WB as late as the next object write?  What is the contract
for volatile variables?  During optimizations, can WB "x" be lazily delayed
until after a later write to object "z"?   I am beginning to see new value
in using substituting write barriers -- it eliminates creating some very
ugly and inflexible contracts between JIT, VM and GC.

I understand the performance potential of optimizing out a write barrier if
the app code is linearly writing many fields of a given object.  I don't
understand if this happens often enough in workloads we care about.  At this
stage of Harmony VM development, perhaps it makes sense to always match a
ref write w/ a WB.  Then let the workloads users care about actually drive
better design if needed.  Isn't arraycopy already a special case?  In
otherwords, it might just be that part the performance potential is already
captured in the special case code for arraycopy of type reference.

If you want to provide an object remembering barrier that the compiler can
call as an optimization, then by all means do so, but the GC should not be
forced to work around compiler 'optimizations' that break fundamental
interface contracts.

While object remembering barriers may be adequate for GCV5 there are a
large family of GC algorithms that they are inadequate for, including
reference counting and concurrent/incremental GCs.


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

> 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

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