RFR (S): 8033380: Experimental VM flag to enforce access atomicity (original) (raw)

Dean Long dean.long at oracle.com
Wed Feb 12 13:24:10 PST 2014

I don't see a _require_atomic_access field in StoreD/LoadD that could be checked, so I guess all platforms are currently guaranteeing volatile double access even when it is not required.

dl

On 2/12/2014 12:29 AM, Aleksey Shipilev wrote:

Thanks Dean!

The study of the compiler code, and the generated assembly, and the empirical tests seems to indicate double accesses are atomic by construction. Either way, we mark the C2 Store/Load nodes to require atomic access. Should there be platform which ignores that flag for doubles, that would mean volatile double access atomicity is broken there as well. This makes the ground for the VM fix, not the additional work for the experimental feature. -Aleksey. On 02/12/2014 01:08 AM, Dean Long wrote: It looks to me that C2 will only look at the atomic flag for longs, not doubles, so if you need atomic access to doubles, I think more work needs to be done.

dl On 2/11/2014 3:02 AM, Aleksey Shipilev wrote: Hi,

I understand we are still closed for integration? Please review this small feature meanwhile: https://bugs.openjdk.java.net/browse/JDK-8033380 http://cr.openjdk.java.net/~shade/8033380/webrev.02/ TL;DR: JMM 9 may need to extend the access atomicity over longs and doubles. Luckily, our logic in emitting the relevant access-atomic instructions is decoupled from memory barriers logic, and so we can "just" unconditionally go through needsatomicaccess where appropriate. Testing: - full cycle JPRT - targeted microbenchmarks on x86/ARM/PPC Thanks, -Aleksey

More information about the hotspot-compiler-dev mailing list