RFR: 8275718: Relax memory constraint on exception counter updates

[David Holmes]

Correction ...

On 3/11/2021 10:09 pm, David Holmes wrote:
> 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.

No that isn't true. I see now that the C++ "Modification Order" 
definition requires the write to the counter to be (for want of a better 
term) "immediately visible" to any subsequent read - so no stale value 
could be read. That is a far stronger guarantee than I expected from 
mo_relaxed. The use of other mo values on the r-m-w atomic operation 
impact the ordering between that variable and other atomic variables.

David
-----

> 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
>>