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