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

[Doug Lea]

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