RFR: AArch64: 8179954: AArch64: C1 and C2 volatile accesses are not sequentially consistent

[White, Derek]

Hi Andrew,

Good catch!

My only comment is in src/cpu/aarch64/vm/templateTable_aarch64.cpp, TemplateTable::getfield_or_static():

The comment in the trailing member around line 2542 says:
 - "It's really not worth bothering to check whether this field really is volatile in the slow case."

But getfield_or_static() is used once to "quicken" getfield byte codes, as well as used forevermore on all getstatic bytecodes (and some weird cases in class sharing?).

I can't claim that makes a definite performance difference (it's just the interpreter), but adding an additional unconditional membar might make it more likely to matter.

FYI, the ppc and arm64 ports do check if the field is volatile before executing the membar (s in the ppc case).

Thanks,

 - Derek

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Aleksey Shipilev
Sent: Tuesday, May 09, 2017 1:30 PM
To: Andrew Haley <aph at redhat.com>; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR: AArch64: 8179954: AArch64: C1 and C2 volatile accesses are not sequentially consistent

On 05/09/2017 07:18 PM, Andrew Haley wrote:
> In C2 we use LDAR/STLR to handle volatile accesses, but in C1 and the 
> interpreter we use separate DMB instructions and relaxed loads. When 
> used together, these do not form a sequentially-consistent memory 
> ordering. For example, if stores use STLR and loads use LDR;DMB a 
> simple Dekker idiom will fail.
> 
> This is extremely hard to test because the loads and stores have to be 
> in separately-compiled methods, but it is incorrect, and likely to 
> fail in very weakly-ordered implementations.
> 
> Note: this is for JDK 9.
> 
>  http://cr.openjdk.java.net/~aph/8179954/

Makes sense to me.

-Aleksey