RFR: 8360654: AArch64: Remove redundant dmb from C1 compareAndSet [v5]

[Ruben]

On Wed, 19 Nov 2025 13:33:09 GMT, Ruben <duke at openjdk.org> wrote:

>> Ping? I don't know what this is for. C1 will only add barriers for pre-LSE systems, and nothing else cares. You've got several new methods that no one needs.
>
> Apologies for the delay in response on this.
> I'm currently reviewing the call sites of these methods in aarch64.ad - like https://github.com/openjdk/jdk/blob/0bff5f3dbe69ab2a59db771af1020b04c0132954/src/hotspot/cpu/aarch64/aarch64.ad#L8491 via https://github.com/openjdk/jdk/blob/0bff5f3dbe69ab2a59db771af1020b04c0132954/src/hotspot/cpu/aarch64/aarch64.ad#L3358, to understand how barriers are handled in C2.

As far as I can tell, this is currently used for codegen of [getAndAddAcquire](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/invoke/VarHandle.html#getAndAddAcquire(java.lang.Object...)).

The method itself doesn't emit a trailing barrier, however a `membar_acquire` is inserted by `C2AccessFence` - https://github.com/openjdk/jdk/blob/0bff5f3dbe69ab2a59db771af1020b04c0132954/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L324-L332
This barrier doesn't appear to be elided.
It seems, in this case the `cmpxchg_barrier` should be used and the `membar_acquire` should be elided. Achieving that would require extra changes - on the C2 side.
If this conclusion is correct, should the extra modification be in scope of this PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26000#discussion_r2542131385