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

[Kim Barrett]

> On May 25, 2020, at 12:23 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> 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.

> 
> Thanks,
> David
> 
>> Cheers,
>> David