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:

"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." [2]

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...)