RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] (original) (raw)
Roman Kennke rkennke at redhat.com
Mon Nov 26 04:58:29 PST 2012
- Previous message: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM]
- Next message: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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).
Roman
- Previous message: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM]
- Next message: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]