RFR: 8166651: OrderAccess::load_acquire &etc should have const parameters (original) (raw)

Andrew Dinn adinn at redhat.com
Thu May 25 14:41:33 UTC 2017

Hi Kim,

On 25/05/17 00:42, Kim Barrett wrote:

_Aside regarding aarch64: I don't know why gcc's atomicload 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 _atomicload rather than atomicloadn.

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

More information about the hotspot-dev mailing list