RFR: 8275718: Relax memory constraint on exception counter updates

[Zhengyu Gu]

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.

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> 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 -----
>
Yes, for this single location atomic counter, there is no ordering involved. Although the counters are not hot, but more restricted memory constraints do not add any values.

Are you okay with this change?

Thanks,

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