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

[Boris Ulasevich]

Hi David,

There is a good Memory Ordering Decorators decription in 
accessDecorators.hpp, see quote below. The example of how MO_RELAXED is 
transformed to machine instructions can be seen in 
barrierSetAssembler_x86.cpp

src/hotspot/share/oops/accessDecorators.hpp
===========================================
// == Memory Ordering Decorators ==
// The memory ordering decorators can be described in the following way:
// === Decorator Rules ===
// The different types of memory ordering guarantees have a strict order 
of strength.
// Explicitly specifying the stronger ordering implies that the 
guarantees of the weaker
// property holds too. The names come from the C++11 atomic operations, 
and typically
// have a JMM equivalent property.
// The equivalence may be viewed like this:
// MO_UNORDERED is equivalent to JMM plain.
// MO_VOLATILE has no equivalence in JMM, because it's a C++ thing.
// MO_RELAXED is equivalent to JMM opaque.
// MO_ACQUIRE is equivalent to JMM acquire.
// MO_RELEASE is equivalent to JMM release.
// MO_SEQ_CST is equivalent to JMM volatile.
//
// === Stores ===
//  * MO_UNORDERED (Default): No guarantees.
//    - The compiler and hardware are free to reorder aggressively. And 
they will.
//  * MO_VOLATILE: Volatile stores (in the C++ sense).
//    - The stores are not reordered by the compiler (but possibly the 
HW) w.r.t. other
//      volatile accesses in program order (but possibly non-volatile 
accesses).
//  * MO_RELAXED: Relaxed atomic stores.
//    - The stores are atomic.
//    - Guarantees from volatile stores hold.
//  * MO_RELEASE: Releasing stores.
//    - The releasing store will make its preceding memory accesses 
observable to memory accesses
//      subsequent to an acquiring load observing this releasing store.
//    - Guarantees from relaxed stores hold.
//  * MO_SEQ_CST: Sequentially consistent stores.
//    - The stores are observed in the same order by MO_SEQ_CST loads on 
other processors
//    - Preceding loads and stores in program order are not reordered 
with subsequent loads and stores in program order.
//    - Guarantees from releasing stores hold.
// === Loads ===
//  * MO_UNORDERED (Default): No guarantees
//    - The compiler and hardware are free to reorder aggressively. And 
they will.
//  * MO_VOLATILE: Volatile loads (in the C++ sense).
//    - The loads are not reordered by the compiler (but possibly the 
HW) w.r.t. other
//      volatile accesses in program order (but possibly non-volatile 
accesses).
//  * MO_RELAXED: Relaxed atomic loads.
//    - The loads are atomic.
//    - Guarantees from volatile loads hold.
//  * MO_ACQUIRE: Acquiring loads.
//    - An acquiring load will make subsequent memory accesses observe 
the memory accesses
//      preceding the releasing store that the acquiring load observed.
//    - Guarantees from relaxed loads hold.
//  * MO_SEQ_CST: Sequentially consistent loads.
//    - These loads observe MO_SEQ_CST stores in the same order on other 
processors
//    - Preceding loads and stores in program order are not reordered 
with subsequent loads and stores in program order.
//    - Guarantees from acquiring loads hold.



On 08.05.2019 15: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
>>