RFR: 8245236: Remove MO_VOLATILE Access decorator

[Kim Barrett]

> On May 19, 2020, at 2:25 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> 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.

Thanks.

> 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

I haven't been following the details of Shenandoah's barrier changes.
Assuming we don't need those functions anymore, getting rid of them
would be a nice additional cleanup for a new RFE.