[aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations

[Yangfei (Felix)]

> On 10/29/19 10:04 AM, Yangfei (Felix) wrote:
> > Currently we have C2 JIT for getAndSetLong like:
> >   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
> >
> >
> > And C2 JIT for compareAndSwapLong like:
> > 433   0x0000ffffa6695088: ldaxr     x8, [x10]
> > 434   0x0000ffffa669508c: cmp       x8, x3
> > 435   0x0000ffffa6695090: b.ne      0x0000ffffa669509c
> > 436   0x0000ffffa6695094: stlxr     w8, x4, [x10]
> > 437   0x0000ffffa6695098: cbnz      w8, 0x0000ffffa6695088
> > 438   0x0000ffffa669509c: cset      x0, eq          ;*invokevirtual
> compareAndSwapLong
> 
> I think this is actually safe whichever order these occur in. However, we might
> as well generate ldaxr/stlxr everywhere.

Thanks.  Will push.  

My thoughts about the risk:  
  Suppose we have T1 executing getAndSetLong on Core1 and T2 executing compareAndSwapLong on Core2.  
  Consider execution order: T1 - > T2  
  The stxr of the getAndSetLong sequence executed on T1/Core1 may not be observed by T2/Core2.  
  The dmb ishld at the end of the getAndSetLong sequence does not ensure the visibility of the stxr, according to the architecture manual.  

Felix