RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile var plus AtomicAccess:: operations [v5]

Stefan Karlsson stefank at openjdk.org
Wed Oct 22 14:51:52 UTC 2025


On Wed, 22 Oct 2025 14:09:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/runtime/atomic.hpp line 299:
>> 
>>> 297:                    atomic_memory_order order = memory_order_conservative) {
>>> 298:     return AtomicAccess::xchg(this->value_ptr(), new_value);
>>> 299:   }
>> 
>> I am not sure I understood the motivation behind the changing of the `xchg` name, nor why `cmpxchg` did not get a similar treatment. Could you provide some elaboration here?
>> 
>> Is there any plan to change the naming in the AtomicAccess layer as well?
>
> The name "xchg" is pretty generic (it could just as easily be used for a
> non-atomic exchange in some other class). The explicit `Atomic::` (now
> `AtomicAccess::`) qualifier made for easy disambiguation. Similarly for the
> others, like "inc" and "dec", and not providing short forms for "add" and
> "sub". (And remember that we mostly eschew operator overloading, though I
> think not always to our benefit. If not for that, such other classes probably
> would be doing that rather than named operations for arithmetic.) I think
> "cmpxchg" is pretty well understood to be atomic; I think if one tried to use
> that name for a non-atomic operation in some other class one might well get
> some push-back.
> 
> Personally, I also find the short names are harder to spot in the middle of
> other code, and I liked that `AtomicAccess::foo` (formerly `Atomic::foo` was
> easy to spot.
> 
> I think updating AtomicAccess to be consistent with what we decide for
> Atomic<T> should be done, but only after Atomic<T> has been fully adopted, so
> we're only dealing the the remaining resudue. This has already been discussed
> with regard to explicit "relaxed" load/store qualifiers.

I don't know if I've said it here or only offline, so I post it here. I would have preferred if this patch retained the names from `AtomicAccess`. I don't think it would be problematic to understand that `var.xchg()` requires you to understand what `var` is. And if you know that `var` is an `Atomic` then you know what `var` is then this is no more confusing than a call to `AtomicAccess::xchg`. The same for `inc` and `dec`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2452374535


More information about the hotspot-dev mailing list