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