RFR(M): 8209420: Track membars for volatile accesses so they can be properly optimized
Roland Westrelin
rwestrel at redhat.com
Wed Aug 22 09:47:13 UTC 2018
> 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.
I pushed this change and filed:
https://bugs.openjdk.java.net/browse/JDK-8209835
for follow up work.
Roland.
More information about the hotspot-compiler-dev
mailing list