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

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.


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 needs_atomic_access where appropriate.
>>> Testing:
>>>    - full cycle JPRT
>>>    - targeted microbenchmarks on x86/ARM/PPC
>>> Thanks,
>>> -Aleksey

More information about the hotspot-compiler-dev mailing list