RFR: 8374878: Add Atomic<T>::compare_set

[Aleksey Shipilev]

On Fri, 9 Jan 2026 12:26:29 GMT, Kim Barrett <kbarrett 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.
>
> src/hotspot/share/runtime/atomic.hpp line 273:
> 
>> 271:   bool compare_set(T compare_value, T new_value,
>> 272:                    atomic_memory_order order = memory_order_conservative) {
>> 273:     return AtomicAccess::cmpxchg(value_ptr(), compare_value, new_value, order) == compare_value;
> 
> I think I would prefer both this and (especially) the translated case be
> 
> return compare_exchange(compare_value, new_value, order) == compare_value;
> 
> rather than duplicating some of the respective `compare_exchange`
> implementations. I won't block for this though.

Thanks. For non-translated version, I agree with the simplification.

For translated case: I actually thought it is a good thing to avoid calling `recover()` on return value, because it did not need to? Does it save anything, really?

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

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