RFR: 8360654: AArch64: Remove redundant dmb from C1 compareAndSet

[Andrew Haley]

On Sat, 17 Jan 2026 04:28:33 GMT, Ruben <duke at openjdk.org> wrote:

> This is duplicate of the PR #26000 which was originally created by @spchee.
> 
> ===========
> 
> AtomicLong.CompareAndSet has the following assembly dump snippet which gets emitted from the intermediary LIRGenerator::atomic_cmpxchg:
> 
> 
> ;; cmpxchg {
>   0x0000e708d144cf60:   mov	x8, x2
>   0x0000e708d144cf64:   casal	x8, x3, [x0]
>   0x0000e708d144cf68:   cmp	x8, x2
>  ;; 0x1F1F1F1F1F1F1F1F
>   0x0000e708d144cf6c:   mov	x8, #0x1f1f1f1f1f1f1f1f
>  ;; } cmpxchg
>   0x0000e708d144cf70:   cset	x8, ne  // ne = any
>   0x0000e708d144cf74:   dmb	ish
> 
> According to the Oracle Java Specification, AtomicLong.CompareAndSet [1] has the same memory effects as specified by VarHandle.compareAndSet which has the following effects: [2]
> 
>> Atomically sets the value of a variable to the
>> newValue with the memory semantics of setVolatile if
>> the variable's current value, referred to as the witness
>> value, == the expectedValue, as accessed with the memory
>> semantics of getVolatile.
> 
> Hence the release on the store due to setVolatile only occurs if the compare is successful. Since casal already satisfies these requirements, the dmb does not need to occur to ensure memory ordering in case the compare fails and a release does not happen.
> 
> Hence we remove the dmb from both casl and casw (same logic applies to the non-long variant)
> 
> This is also reflected by C2 not having a dmb for the same respective method.
> 
> [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/concurrent/atomic/AtomicLong.html#compareAndSet(long,long)
> [2] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndSet(java.lang.Object...)

The problem with this PR is that the existing CAS implementation in HotSpot is a complicated mess, and adding to it inevitably makes things worse. That's not your fault, but we have to deal with it.

Today we have this:


  void cmpxchg(Register addr, Register expected, Register new_val,
               enum operand_size size,
               bool acquire, bool release, bool weak,
               Register result);



Adding a bunch of `_barrier` methods doesn't help.

Maybe try something like this:


  void cmpxchg(Register addr, Register expected, Register new_val,
               enum operand_size size,
               unsigned flags,
               Register result);

  enum {
    MO_ACQUIRE = 1, MO_RELEASE = 2, MO_WEAK = 4, MO_SEQ_CST = 8, MO_FULL_BARRIER = 16
  }

So this:

    cmpxchg(/*addr*/ obj, /*expected*/ t1_mark, /*new*/ t3_t, Assembler::xword,
            /*acquire*/ true, /*release*/ true, /*weak*/ false, noreg);

turns into this:

    cmpxchg(obj, /*expected*/ t1_mark, /*new*/ t3_t, Assembler::xword, MO_ACQUIRE | MO_RELEASE, noreg);


A patch to do this will be far more extensive than this PR, but we can't go any further without paying back technical debt.

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

PR Comment: https://git.openjdk.org/jdk/pull/29287#issuecomment-3846253988