RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] (original) (raw)

Doug Lea dl at cs.oswego.edu
Mon Nov 26 06:31:13 PST 2012

On 11/26/12 07:58, Roman Kennke wrote:

Am Montag, den 26.11.2012, 09:50 +0000 schrieb Andrew Haley:

On 11/23/2012 05:14 PM, Roman Kennke wrote:

Alright, I found another fairly grave bug that I would like to include a fix for: apparently, a 'fence' is not enough of a memory barrier for volatile putfield/getfield (duh). Which basically broke all of j.u.c. LLVM offers atomic loads and stores, which seem to be exactly what is needed for volatile field access. However, it does not provide helper functions for those in llvm::IRBuilder so I wrote my own. This should be the final patch for now (unless you find something else). http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ I note that you've used llvm::SequentiallyConsistent for all the atomic accesses. This looks right to me, but if there's any doubt you could ask Doug Lea. Yeah. Except for monitorenter and monitorexit, where I used Acquire and Release (which I believe is right too, at least it seems very sensible :-) ). The other access flags (unordered and monotonic) don't seem to have a mapping in Java, except maybe in some of the many Unsafe intrinsics, but they are not implemented in Shark (yet).

I don't much about how llvm maps modes to internals, but so long as you are using atomic updates for lock/unlock, the LLVM documentation implies that this is fine. (See http://llvm.org/docs/Atomics.html) The mappings for other intrinsics (like putOrderedX) also seem straightforward, but leaving all of them as SequentiallyConsistent for now will suffice.

-Doug

More information about the hotspot-dev mailing list