RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile var plus AtomicAccess:: operations
Kim Barrett
kbarrett at openjdk.org
Thu Nov 13 08:39:15 UTC 2025
On Fri, 3 Oct 2025 11:48:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> 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.
>
>> How do we resolve this? I feel like this whole PR is stuck here.
>
> Just a reminder that I wrote:
>> The following isn't a strong request, but maybe more of stated preference and an inquiry what other HotSpot devs think about the proposed names
>
> I really would have liked to hear from other Reviewers what they think. So, I've been waiting for others to chime in. If I'm really alone in my lack of enthusiasm for the names `relaxed_store` / `load_releaxed` then so be it.
>
> If you are going to skip the names Atomic<T>::load/store will you also update the names AtomicAccess<T>::load/store in a follow-up RFE?
Thanks for reviews @stefank , @xmas92 , and @jdksjolen
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3526453895
More information about the hotspot-dev
mailing list