RFR: 8247524: Remove unnecessary volatile qualifiers from member functions

[Kim Barrett]

> On Jun 15, 2020, at 9:09 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 15/06/2020 6:56 pm, Kim Barrett wrote:
>>> On the other hand for a mutable field e.g.:
>>> 
>>> size_t size() const volatile { return _word_size; }
>>> 
>>> I can see an expectation that the volatile would force the compiler to always reload _word_size, even if the field itself was not declared volatile (which it isn't). Isn't this how we are now handling things via Atomic::load - where the field is no longer flagged volatile but the load is so that we still tell the compiler not to make assumptions about potentially caching the field?
>> The “preferred" way to do that today would be to make the member volatile and use Atomic
>> accesses (possibly relaxed if no ordering is needed).  Or just rely on the volatile qualified
>> member (though that’s no longer “preferred”).  (And AtomicValue<> might be used in the
>> future, instead of a volatile member.)
> 
> So I'm reminded that there is currently disagreement about what the new "preferred way" for this, but lets leave that for the AtomicValue discussion. :)

Hence my use of quotations :)  And yes, let’s have that discussion over there.

>> But in this case, none of that matters.  The _word_size is initialized by the constructor and
>> is never modified - there are no calls to set_size.  I should have removed set_size but
>> forgot; I’ll fix that now.  And it looks like there are a whole bunch of unused or seemingly
>> useless functions in Metabase.
> 
> I saw set_size, hence my query, but didn't look that it was actually used :)
> 
> I'm fine with the current set of changes.

Thanks.