RFR: 8275718: Relax memory constraint on exception counter updates

[Aleksey Shipilev]

On Thu, 21 Oct 2021 15:16:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> This is another instance of counter updates that only need atomic guarantee.

(I am not arguing in favor or against this particular change, but I think we can talk a bit about generic stuff here...)

> I don't know where this guarantee is coming from. Two r-m-w atomic ops must have some guarantee via coherence for the atomic op to actually work. And an implementation could make any atomic r-m-w implementation ensure global immediate visibility. But you cannot assume this is guaranteed for all hardware. Even for a given platform this would need to be a specified guarantee in the architecture manual, not just something deduced/inferred by reasoning.

Hotspot's `memory_order_relaxed` is [aligned](https://github.com/openjdk/jdk/blob/5bb1992b8408a0d196b1afa308bc00d007458dbd/src/hotspot/share/runtime/atomic.hpp#L44-L45) with C++11 atomics semantics. C++11 atomic semantics for relaxed atomic ops requires [single modification order consistency](https://en.cppreference.com/w/cpp/atomic/memory_order#Relaxed_ordering), which implies [coherence](https://en.cppreference.com/w/cpp/atomic/memory_order#Modification_order).

All known hardware platforms provide coherence out of the box (they are, indeed, cache-coherent platforms), that's why it is easy to implement in C++ (`mo_relaxed`) and in Java (`VarHandles.(get|set)opaque`).

I am always confused by "immediate global visibility". The problem with statements that include "immediate", "before", "after" is that they leak in the notion of time, which is ill-defined for a single memory location without any reference to other variables. Maybe you can expand your concern with the example?

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

PR: https://git.openjdk.java.net/jdk/pull/6065