RFR: 8245236: Remove MO_VOLATILE Access decorator

[Stefan Karlsson]

On 2020-05-19 07:24, Kim Barrett wrote:
> Please review this change with replaces uses of the MO_VOLATILE memory
> order Access decorator with uses of the MO_RELAXED decorator.  Uses of
> MO_VOLATILE generally assume non-word-tearing semantics, so a relaxed
> atomic access is more appropriate.  As a result, we can eliminate the
> MO_VOLATILE decorator.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8245236
>
> Webrev:
> https://cr.openjdk.java.net/~kbarrett/8245236/open.00/
Looks good.

One reflection after reading this.

  markWord oopDesc::mark() const {
- uintptr_t v = HeapAccess<MO_VOLATILE>::load_at(as_oop(), 
mark_offset_in_bytes());
+ uintptr_t v = HeapAccess<MO_RELAXED>::load_at(as_oop(), 
mark_offset_in_bytes());
    return markWord(v);
  }
  
  markWord oopDesc::mark_raw() const {
    return Atomic::load(&_mark);

and

  void oopDesc::set_mark(markWord m) {
- HeapAccess<MO_VOLATILE>::store_at(as_oop(), mark_offset_in_bytes(), 
m.value());
+ HeapAccess<MO_RELAXED>::store_at(as_oop(), mark_offset_in_bytes(), 
m.value());
  }
  
  void oopDesc::set_mark_raw(markWord m) {
    Atomic::store(&_mark, m);
  }

I noticed that the normal versions use HeapAccess and the _raw versions 
use Atomic::. The _raw versions where added to support Shenandoah's load 
barriers, but they have since changed their load barriers and don't need 
these functions anymore (AFAIK). Maybe its time to clean this up and get 
rid of all the _raw versions added for Shenandoah.

StefanK

>
> Testing:
> mach5 tier1.
>