RFR(M): 8209420: Track membars for volatile accesses so they can be properly optimized

Andrew Haley aph at redhat.com
Mon Aug 13 16:33:36 UTC 2018


On 08/13/2018 03:38 PM, Roland Westrelin wrote:
> 
> http://cr.openjdk.java.net/~roland/8209420/webrev.00/

Thanks, this is a great improvement.

I notice that this works for simple volatile access, but it does not
work for read-modify write operations such as, say,
VarHandle.getAndAdd(), where the barrier instructions are not elided:

 ;; membar_release
  0x000003ffa8b049b8: dmb	ish
  0x000003ffa8b049bc: add	x10, x19, #0xc
  0x000003ffa8b049c0: ldxr	wscratch2, [x10]
  0x000003ffa8b049c4: add	wscratch1, wscratch2, #0x1
  0x000003ffa8b049c8: stxr	wscratch2, wscratch1, [x10]
  0x000003ffa8b049cc: cbnz	wscratch2, 0x000003ffa8b049c0
  0x000003ffa8b049d0: sub	w10, wscratch1, #0x1
 ;; membar_acquire
  0x000003ffa8b049d4: dmb	ishld                       ;*invokevirtual getAndAddInt {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.invoke.VarHandleInts$FieldInstanceReadWrite::getAndAdd at 19 (line 206)
                                                            ; - java.lang.invoke.VarHandleGuards::guard_LI_I at 33 (line 129)
                                                            ; - Sync::run at 42 (line 35)

I think we need to be consistent about how we handle these operations.

-- 
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 hotspot-compiler-dev mailing list