RFR: 8245594: Remove volatile-qualified member functions and parameters from oop class

[coleen.phillimore at oracle.com]

On 5/21/20 6:31 PM, Kim Barrett wrote:
> Please review this change to eliminate volatile qualification in the
> member functions and parameters of the oop class and its subclasses.

This is nice.  I thought more code would fail to compile if the volatile 
versions were removed, which is why they were added in the first place.  
It does not look like this is the case since this changeset is small.
>
> Removed volatile qualified member functions and parameters from class
> oop and its subclasses (instanceOop, arrayOop, objArrayOop, typeArrayOop).
> Changed the few remaining volatile oop accesses to instead use relaxed
> atomics.
"relaxed atomics" means Atomic::load(&_field) ?

So if the field is declared "volatile", will the compiler give you an 
error if you just store a value to it without Atomic::store(&_field) ?  
But it will not give you an error if you fail to load the value without 
Atomic::load(&_field).  But keeping the "volatile" keyword on 
declarations is a good way to visually signal that this variable needs 
special access?

Thanks for cleaning the oop class up.

Coleen
>
> Changed constructors for MemoryManager and MemoryPool to use
> initializer list, so we don't need to use Atomic::store to initialize
> an oop-derived member.
>
> Eliminated ShenandoahVerifierTask's volatile-qualified assignment
> operator, which isn't used.
>
> Some tidying up oop class. Cleaned up constructors, eliminating public
> set_obj(). Use const-ref rather than by-value parameters for comparisons,
> to avoid unnecessary copies that go through register/deregister.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8245594
>
> Webrev:
> https://cr.openjdk.java.net/~kbarrett/8245594/open.00/
>
> Testing:
> mach5 tier1-5
> Local (linux-x64) hotspot:tier1 with Shenandoah enabled.
>