RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE [v2]

[David Holmes]

On Tue, 19 Aug 2025 15:58:52 GMT, Samuel Chee <duke at openjdk.org> wrote:

>> According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]:
>> 
>>> 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.
>> 
>> Thus, the store-release 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 store-release does not happen.
>> 
>> Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB).
>> 
>> The unused cmpxchgw is removed.
>> 
>> [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...)
>
> Samuel Chee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge master fix
>   
>   Change-Id: I74d44f711de208395bce47595fecd801564bcb54

Not sure why you are using the specification for the Java API cmpxchg function to determine what the MacroAssembler function does?? Is this the intrinsic for the Java code?

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

PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3206161458