RFR (S): 8033380: Experimental VM flag to enforce access atomicity
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
> 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.
> 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.
>> On 2/11/2014 3:02 AM, Aleksey Shipilev wrote:
>>> I understand we are still closed for integration?
>>> Please review this small feature meanwhile:
>>> 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.
>>> - full cycle JPRT
>>> - targeted microbenchmarks on x86/ARM/PPC
More information about the hotspot-compiler-dev