RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2]

[Aleksey Shipilev]

On Mon, 18 Nov 2024 09:36:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks.
>> 
>> I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp
>
>> > It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks.
>> 
>> I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp
> 
> No need. If we go down that road, we also want to rename `lir_move_volatile` and all that jazz, which would probably entail a few rounds of careful looking. Submit a follow-up issue for it instead.

> I guess @shipilev is the authorative source here, but my reading of JDK-8033380 is that it intended for all long/double accesses to be treated just like volatile double/long accesses - and hence wanted atomicity and membars.

Atomic here means single-copy atomicity, not memory ordering. So this PR does the semantics right.

> That said here we are 10 years down the track and the JMM update never eventuated. Is this code even still warranted? Does this mean the JMM update efforts are reviving?

Context: one of our high-load services uses `long` counters, and we are looking for the ways to guarantee single-copy atomicity for them without going for `volatile long`. It "kinda" works that way on 64-bit platforms, but we want to be extra sure. If that project ran on JDK 9+ language level, we would have used `VarHandle.(get|set)Opaque`. On JDK 8 language level, we could use `LongAdder` if we could have accepted the larger per-counter footprint. But when we cannot afford `LongAdder`, then on modern JVM we can use plain `long` field with `-XX:+AlwaysAtomicAccesses`. So this option is still marginally useful, albeit in darker corner cases :)

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

PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2484898519