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

[Kim Barrett]

On Sun, 28 Sep 2025 11:10:41 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds the type Atomic<T>, to use as the type
> of a variable that is accessed (including writes) concurrently by multiple
> threads. This is intended to replace (most) uses of the current HotSpot idiom
> of declaring a variable volatile and accessing that variable using functions
> from the AtomicAccess class.
> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
> 
> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
> 
> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
> operationally the same, with the same API, hence uses and gtests didn't need
> to change in that respect. Thanks to @stefank for raising this issue, and for
> some suggestions toward improvements.
> 
> * Changed how fetch_then_set for atomic translated types is handled, to avoid
> having the function there at all if it isn't usable, rather than just removing
> it via SFINAE, leaving an empty overload set.
> 
> * Added more gtests.
> 
> Testing: mach5 tier1-6, GHA sanity tests

I agree the similarity between `relaxed_store` and `release_store` isn't
ideal. I think unqualified `load` and `store` is worse.

> Atomic r-m-w operations (pretty much everything except base load/store) were
> required to have full bi-directional fence semantics from "day one". That
> doesn't make sense for base load/store so they are "relaxed" by default.

That's only true in the HotSpot API. It's not true for C++ <atomic> or the C
equivalent, or in most published papers, where the default for "atomic" loads
and stores is sequentially consistent. So we're weird that way. We don't even
directly have those operations (though they can probably be more or less
simulated using RMW operations).

> I personally hate the term "relaxed" as it suggests to me a removal of
> "normal" ordering, when really it means the absence of a stronger ordering.

I agree that "relaxed" doesn't seem like the greatest of terms. But I think
it's the generally accepted term in this area. At least, it's what's used for
C/C++ <atomic> and friends. (But maybe I'm wrong about it being generally
accepted? Looking through some papers, I'm not always finding that
nomenclature.)

So it might be a mistake to invent our own terminology. But for the sake of
discussion I'll throw out one idea: "unordered".

(I think "atomic" has the right technical meaning (indivisible, i.e. no
tearing, but doesn't imply ordering), but is probably too confusing. It would
also require something different for the proposed `atomic_inc()` and
`atomic_dec()` member functions.)

How do we resolve this? I feel like this whole PR is stuck here.

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3364872165