The VarHandle spec should make the semantics of "mixed" access clearer.

Suppose two accesses to the same memory location use both VarHandle and non-VarHandle access:

volatile long x;
VarHandle X = ..."x"
...
x = 2;
...
X.compareAndSet(1, 3);

On a 32-bit platform with atomic 64-bit loads and stores but no 64-bit CAS, ordinary accesses are likely to be compiled to a single instruction, whereas the CAS must use a lock. And the assignment must use the same lock to preserve CAS atomicity.

Perhaps it's simply time to de-support platforms without 64-bit atomics.
(Are there any platforms currently running java with this problem?)
(currently openjdk apparently uses a global lock to implement VarHandles on such platforms, which is unsatisfactory even when correct).

(See VMSupportsCS8())

Current specs say,
"""When mixed access is performed extreme care should be taken since the Java Memory Model may permit surprising results."""
but it's not clear what kind of mixed mode access is meant: VarHandle vs. non-VarHandle, or sequentially consistent vs. relaxed (but the relaxed access is only possible via VarHandle).

It seems like C++ avoids this sort of issue by requiring an atomic<T> declaration, which can efficiently gate the use of a lock only where required. That seems like a better design, but too late to adopt for java?

Java may have this problem in a bigger way when Valhalla introduces value types larger than 64 bits.