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

[David Holmes]

After discussing with Kim off-line I need to clarify some comments ...

On 25/05/2020 12:32 pm, David Holmes wrote:
> On 25/05/2020 10:53 am, Kim Barrett wrote:
>>> On May 24, 2020, at 8:01 PM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>
>>> Okay this is really nothing to do with Atomic::store at all. using 
>>> the initializer list is the obviously correct and simple way to do this.
>>
>> There are many reasons to prefer using initializer lists for
>> initialization. In this case, one is not needing to have a weak atomic
>> store, as those generally engender additional scrutiny.  I guess my
>> RFR description was overly terse and suggested more than was intended.
>>
>>>>> Hmmm. Granted "volatile" on a Class type has no meaning. But I 
>>>>> always think of oop as really being a pointer type so volatile 
>>>>> actually makes some sense there.
>>>>> […]
>>>
>>> Okay, but I still don't see why we would not remove the volatile 
>>> qualifier for these oop cases.
>>
>> It "tags" the variable as being read/written by multiple threads and
>> semantically atomic. And unlike similar usage with fundamental types,
>> because we've eliminated the volatile qualifiers in member functions,
>> the compiler will help us remember to use atomic accesses.
> 
> I have no issue with using "volatile" as a tag but I'm confused that we 
> now will have two distinct conventions in this area.

The convention I'm referring to is one that has been discussed in the 
context of other code-reviews, is partly behind

https://bugs.openjdk.java.net/browse/JDK-8234192

(though that also leads to a full blown AtomicVal<T> style of API), and 
which is clearly demonstrated by the proposal in:

https://bugs.openjdk.java.net/browse/JDK-8238174

and which involves removing use of the volatile qualifier once we have 
switched to using Atomic::load/store for accesses.

Hence my confusion as to why the volatile qualifier is not only being 
retained in this code, but is seen as a good thing to have for 
documenting the fact this member is special.

Anyway, as these "conventions" are still TBD and not widely endorsed 
yet, I won't delay Kim's current updates any further.

Thanks,
David

> Cheers,
> David
>