Atomic operation barriers in x64 are not elided according to the expectations described in ZBarrierSetC2::analyze_dominating_barriers(). For example, an atomic operation on an object field followed by a load of the same field does not result in the load's barrier being elided.

To reproduce the issue, run Atomics.java (attached) in x64 as follows:

$ java -Xbatch -XX:-TieredCompilation -XX:+UseZGC -XX:CompileOnly=Atomics::testAtomicThenLoad -XX:CompileCommand=PrintAssembly,Atomics::testAtomicThenLoad Atomics.java | grep BarrierStubC2

According to the logic described in ZBarrierSetC2::analyze_dominating_barriers(), we would expect the following output (the load's barrier should be elided):

;; ZStoreBarrierStubC2

However, we get:

;; ZStoreBarrierStubC2
;; ZLoadBarrierStubC2

In x64, this is a regression introduced by JDK-8297235, where the memory operands of atomic instructions were changed from 'memory' to 'indirect'. This inhibits C2 from deriving the atomic access offset, and as a result ZBarrierSetC2::analyze_dominating_barriers_impl() cannot match dominating/dominated access pairs when at least one of these is an atomic operation. Most likely this is an issue in all other platforms as well, where the memory operands of atomic instructions where already of type 'indirect' before JDK-8297235, but they remain to be tested. The same problem can be expected for volatile loads and stores in aarch64 (zLoadPVolatile, zStorePVolatile), whose memory operand is of type 'indirect'.

As far as I can see, this issue results in missing optimizations but does not cause malfunctioning.