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

[Andrew Dinn]

Hi Kim,

On 25/05/17 00:42, Kim Barrett wrote:
> <snip>
> 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.

This is braaking when I compile it on AArch64. Specifically, it's the
void * atomic load definition in orderAccess_linux_aarch64.inline.hpp
that is causing the problem. Here is one of many errors:

In file included from
/home/adinn/openjdk/jdk10-hs/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:33:0,
  ...
/home/adinn/openjdk/jdk10-hs/hotspot/src/os_cpu/linux_aarch64/vm/orderAccess_linux_aarch64.inline.hpp:
In static member function ‘static void*
OrderAccess::load_ptr_acquire(const volatile void*)’:
/home/adinn/openjdk/jdk10-hs/hotspot/src/os_cpu/linux_aarch64/vm/orderAccess_linux_aarch64.inline.hpp:77:59:
error: invalid const_cast from type ‘const volatile void*’ to type
‘void* volatile*’
 { void* data; __atomic_load(const_cast<void* volatile *>(p), &data,
__ATOMIC_ACQUIRE); return data; }

The new declaration doesn't exactly look very convincing (but then nor
did the old one. Here is the relevant change:

 ...
 inline void*    OrderAccess::load_ptr_acquire(const volatile void* p)
-{ void* data; __atomic_load((void* const volatile *)p, &data,
__ATOMIC_ACQUIRE); return data; }
+{ void* data; __atomic_load(const_cast<void* volatile *>(p), &data,
__ATOMIC_ACQUIRE); return data; }
 ...

I'm still puzzling over what is actually needed to do the right job
here. I can see why you have made the change the way you have but the
compiler definitely does not want to eat it. I'll play with the code and
see what does compile.

Oddly enough, I have just posted a fix to jdk10-dev (I forwarded the
original note to hotspot-dev but the discussion now seems to be
progressing in jdk10-dev -- apologies) that relates to a use of this
code and to the correct declaration of volatile fields that store
pointers vs fields that store volatile pointers). It might be worth
looking at that to see if it bears on this issue.

regards,


Andrew Dinn
-----------

Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander