RFR: 8275718: Relax memory constraint on exception counter updates

[David Holmes]

On 1/11/2021 7:16 pm, Aleksey Shipilev wrote:
> 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?

Let me back up to be clear. I stated that memory-order-conservative 
might lower the chances (in a general platform-agnostic way) of seeing a 
stale value, compared to memory-order-relaxed, due to the stronger 
memory fence/barrier operation it implies. The response to that was:

"value updated via atomic r-m-w operation should be visible to other 
threads guaranteed by coherence protocol"

claiming that visibility guarantees were inherently present due to 
coherence regardless of what kind of memory fence/barrier were 
associated with the r-m-w atomic operation. I'm not sure if that is 
actually true. If it is true then we would not need any memory-order 
parameter on the r-m-w atomic operations because they would be all be 
the same due to this underlying coherence property.

When I said "immediate global visibility" I was referring to a situation 
where once the write in the r-m-w atomic op had occurred then all 
subsequent reads would see the value of that write. It is true that such 
a thing may not require "immediacy" in a temporal sense, but the net 
effect is the same.

David
-----

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