Java opaque memory order

[Peter Veentjer]

Hi,

My question is about the Java opaque memory order. E.g. the VarHandle.getOpaque or setOpaque.

Opaque doesn't provide ordering for surrounding loads/stores to different addresses. It will ensure coherence (so loads/stores to the same address can't be reordered).

Example:

https://github.com/openjdk/jcstress/blob/master/jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/basic/BasicJMM_05_Coherence.java

Opaque will provide visibility and atomicity. Opaque is great for performance counters or progress indicators assuming there is no reliance on any other fields before or after that counter. 

It can be used in similar situations as memory_order_relaxed from C++.

AFAIK opaque can be implemented by just inserting a compiler barrier since all modern CPUs are coherent and will ensure that stores become visible eventually.

The question is the following: assuming that an opaque field is used appropriately, is there any risk in using opaque? Is there any chance that a JVM will go up in flames or start to take over the world.

[Aleksey Shipilev]

On 1/20/25 08:24, Peter Veentjer wrote:
> The question is the following: assuming that an opaque field is used appropriately, is there any
> risk in using opaque? Is there any chance that a JVM will go up in flames or start to take over the
> world.

Generic (scary) answer: With complex optimizing compilers, there is always a risk in using stuff you
have not touched before: if intermediate representation of the program changes, it may take compiler
to the paths it was not visiting before in the similar conditions.

Specific (non-scary) answer: ...but I would estimate the risk for additional compiler barriers
Opaque emits is slim to none. To begin with, the compiler barriers emitted around Opaque are the
subset of barriers emitted for Acquire/Release/Volatile accesses already.

-Aleksey