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

[Aleksey Shipilev]

Yes, that's my understanding as well.

-Aleksey.

On 02/13/2014 01:24 AM, Dean Long wrote:
> 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 needs_atomic_access where
>>>> appropriate.
>>>>
>>>> Testing:
>>>>    - full cycle JPRT
>>>>    - targeted microbenchmarks on x86/ARM/PPC
>>>>
>>>> Thanks,
>>>> -Aleksey
>