[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