RFR: 8166651: OrderAccess::load_acquire &etc should have const parameters

[Kim Barrett]

> On May 25, 2017, at 7:43 AM, coleen.phillimore at oracle.com wrote:
> 
> Looks good.
> Coleen

Thanks.

> 
> On 5/25/17 4:44 AM, David Holmes wrote:
>> Hi Kim,
>> 
>> On 25/05/2017 9:42 AM, Kim Barrett wrote:
>>> Please review this change to Atomic::load and OrderAccess::load_acquire
>>> overloads to make their source const qualified, e.g. instead of
>>> "volatile T*" make them "const volatile T*".  This eliminates the need
>>> for casting away const when, for example, applying one of these
>>> operations to a member variable when in a const-qualified method.
>> 
>> This looks quite reasonable - thanks - provided ...
>> 
>>> There are probably places that previously required casting away const
>>> but now do not. Similarly, there are probably places where values
>> 
>> ... our compilers do not complain about unnecessary casts :)
>> 
>> Cheers,
>> David
>> 
>> 
>>> couldn't be const or member functions couldn't be const qualified, but
>>> now can be. I did a little searching and found a few candidates, but
>>> none that were otherwise trivial to add to this change, so haven't
>>> included any.
>>> 
>>> This change touches platform-specific code for non-Oracle supported
>>> platforms that I can't test, so I'd like reviews from the respective
>>> platform owners.
>>> 
>>> Aside regarding aarch64: I don't know why gcc's __atomic_load doesn't
>>> const-qualify the source argument; that seems like a bug.  Or maybe
>>> they are, but not documented that way.  And I wonder why the aarch64
>>> port uses __atomic_load rather than __atomic_load_n.
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8166651
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8166651/hotspot.00
>>> 
>>> Testing:
>>> JPRT