RFR: 8166651: OrderAccess::load_acquire &etc should have const parameters
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Thu May 25 11:43:56 UTC 2017
Looks good.
Coleen
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
>>
More information about the hotspot-dev
mailing list