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

[David Holmes]

Thanks Erik and Boris for your replies and fixing my ignorance. I surely 
knew this at some time:

http://gee.cs.oswego.edu/dl/html/j9mm.html

David

On 8/05/2019 10:12 pm, Erik Österlund wrote:
> 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
>>>
>