RFR (S) 8223472: volatile long field corruption on x86_32

[Erik Österlund]

Hi David,

The name "relaxed" comes from std::memory_order_release, which implies 
atomicity.

 From accessDecorators.hpp:
"MO_RELAXED is equivalent to JMM opaque."

 From JMM opaque definition on Doug Lea's website:
"If Opaque (or any stronger) mode is used for all accesses, then reads 
of all types, including long and double, are guaranteed not to mix the 
bits of multiple writes." (i.e. atomicity)

In the implementation of the access for x86 (_32) 
BarrierSetAssembler::store_at, the backend looks at MO_RELAXED and uses 
that to determine if the access should be atomic.
So it is quite intentional that a relaxed access is indeed atomic.

/Erik

On 2019-05-08 14:01, David Holmes wrote:
> I would very much like an explanation of how this lack of MO_RELAXED 
> causes a lack of _atomicity_! What has "MO" got to do with that? And 
> why would a volatile access be "relaxed" or "unordered"?
>
> This is not making any sense to me at all.
>
> Thanks,
> David
>
> On 8/05/2019 7:07 pm, Erik Österlund wrote:
>> Hi Boris,
>>
>> Thank you for fixing this. Looks good to me.
>>
>> /Erik
>>
>> On 2019-05-08 10:17, Boris Ulasevich wrote:
>>> Hi all,
>>>
>>> Please review a simple change to fix long field store atomicity for 
>>> 32-bit x86 interpreter.
>>>
>>> http://bugs.openjdk.java.net/browse/JDK-8223472
>>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00
>>>
>>> thanks,
>>> Boris
>>