Was discussed on the mailing list, but an issue for completeness.
I compared it with the JMM Cookbook and the implementation of x10.util.concurrent.Fences follows it very directly. For example, "volatile load then volatile store means loadStore barrier".
The problem is the JMM considers volatile variables separately, so the
JVM can optimize volatiles. If the JVM figures out the volatile
variables in FencesUtils.java are never accessed concurrently, then they
can be optimized away. I made a toy example and this became
No synchronization instruction. The other three barriers contained a
"lock addl" instruction.
I think this sometimes might work, but not reliably. Afaik there is no
way to correctly implement FencesUtils.java. This implies
x10.util.concurrent.Fences cannot be provided with the Java backend.