[aarch64-port-dev ] [NEW BUG]Missing LoadStore barrier in interpreter?
Patrick Zhang
patrick at os.amperecomputing.com
Sun Feb 3 02:55:28 UTC 2019
> It's not necessary because of the x86 TSO memory model.
Hi Andrew,
Could you please explain this a little bit more? It looks aarch64 has a StoreLoad there, while x86 has StoreLoad|StoreStore, did you mean the StoreStore can be dropped by aarch64 because x86 TSO needs more protection here? Thanks.
http://hg.openjdk.java.net/jdk/jdk/file/00baec44c94e/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp#l2723
__ membar(MacroAssembler::StoreLoad);
http://hg.openjdk.java.net/jdk/jdk/file/00baec44c94e/src/hotspot/cpu/x86/templateTable_x86.cpp#l3134
volatile_barrier(Assembler::Membar_mask_bits(Assembler::StoreLoad | Assembler::StoreStore));
Regards
Patrick
-----Original Message-----
From: Andrew Haley <aph at redhat.com>
Sent: Saturday, February 2, 2019 9:43 PM
To: Patrick Zhang <patrick at os.amperecomputing.com>; Lun Liu <lunliu93 at gmail.com>; aarch64-port-dev at openjdk.java.net
Cc: jiangning.liu at os.amperecomputing.com
Subject: Re: [aarch64-port-dev ] [NEW BUG]Missing LoadStore barrier in interpreter?
On 2/2/19 3:47 AM, Patrick Zhang wrote:
> 1. Is the right process that the patch firstly gets applied on jdk/jdk/../aarch64, then backported to jdk8u?
Yes.
> BTW, I wonder if there is any "failed" test, and right now could get "pass" with the patch?
> http://hg.openjdk.java.net/jdk/jdk/file/00baec44c94e/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp#l2723
We could try to write a custom jcstress test, but I don't think there's much point..
> 2. Compared the original patch (back to Jun 2013) on aarch64-port/jdk8u with x86's implementation, at the end of the putfield_or_static function, was the StoreStore intentionally dropped?
> http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/ed26923dcc83#l3.118
> http://hg.openjdk.java.net/jdk/jdk/file/00baec44c94e/src/hotspot/cpu/x86/templateTable_x86.cpp#l3134
> - // TODO : restore this volatile barrier call
It's not necessary because of the x86 TSO memory model.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the aarch64-port-dev
mailing list