RFR: 8374878: Add Atomic<T>::compare_set [v2]

[Axel Boldt-Christmas]

On Fri, 9 Jan 2026 17:55:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Following up on [JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013) improvement, there is an opportunity to rewrite some of our low-level `cas(oldv, newv) == oldv` patterns to more straight-forward compare-and-set helper method. This is useful when you do not actually care about the result that used to be in memory or that is currently in memory, you only care if CAS succeeded or not.
>> 
>> Java atomics already have this duality; arguably due to historical timeline of having compare-and-set before introducing compare-and-exchange.
>> 
>> Found this when converting Epsilon to Atomic<T> ([JDK-8374876](https://bugs.openjdk.org/browse/JDK-8374876)), where this method would simplify the code a bit. I looked around current uses of `compare_exchange` and rewrote them to `compare_set` to show what simplifications are possible.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Missed another use
>  - Delegate non-translating version
>  - Merge branch 'master' into JDK-8374878-atomic-compare-set
>  - Indenting is a bit off
>  - Fix

src/hotspot/share/runtime/atomic.hpp line 492:

> 490:     return _value.compare_set(decay(compare_value),
> 491:                               decay(new_value),
> 492:                               order);

This is subtly different from what we usually did with AtomicAccess / Atomic compare_exchange on translated types. We used to check equality with the `bool operator==(const T&, constT&)` rather than `bool operator==(const PrimitiveConversions::Translate<T>::Decayed&, const PrimitiveConversions::Translate<T>::Decayed&)`.

For the `PrimitiveConversions::Translate` we currently have I do not think there is an issues as they are `memcmp` equivalent in both cases. But we may introduce a PrimitiveConversion in the future where this is not the case and this function returns false when using `recover` and `bool operator==(const T&, constT&)` would have returned true.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29135#discussion_r2681709542