[aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations
Andrew Haley
aph at redhat.com
Sat Sep 7 12:57:00 UTC 2019
On 8/28/19 11:39 AM, Yangfei (Felix) wrote:
>> Having said that, I can sort-of imagine a jcstress failure if we had a test that was doing compareAndSwap in one thread and getAndSet in another. That would be a seriously compelling reason for a backport!
> Can you elaborate more please? especially the possible code sequence.
>
> Currently, we have C2 JIT for getAndSet like this:
>
> 33 ;; membar_release
> 34 0x0000ffffa416ae74: dmb ish
> 35 ;; 0x40000000000
> 36 0x0000ffffa416ae78: orr x11, xzr, #0x40000000000
> 37 0x0000ffffa416ae7c: add x10, x1, #0x10
> 38 0x0000ffffa416ae80: prfm pstl1strm, [x10]
> 39 0x0000ffffa416ae84: ldxr x9, [x10]
> 40 0x0000ffffa416ae88: stxr w8, x11, [x10]
> 41 0x0000ffffa416ae8c: cbnz w8, 0x0000ffffa416ae84
> 42 0x0000ffffa416ae90: mov x10, x9
> 43 ;; membar_acquire
> 44 0x0000ffffa416ae94: dmb ishld ;*invokevirtual getAndSetLong
The important thing is that there should be a StoreLoad barrier between a
volatile store and a volatile load. If we have a getAndSet followed by a
CompareAndExchange that might not happen.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the aarch64-port-dev
mailing list