[jmm-dev] Specifying VarHandle acquire/release without ill effects

[Doug Lea]

On 06/17/2016 04:08 AM, Andrew Haley wrote:
> On 16/06/16 21:28, Aleksey Shipilev wrote:
>
>> The clause about reorderings trips users into believing that
>> getAcquire and putRelease have fence-like semantics.

You are right that we should clarify.

> I've read this several times now and I still do not understand it.
> Release and acquire are well-defined terms in the industry, and I
> can't think of any great reason to add more words like yours,

But maybe some other words. Backing up:

The rationale for the JMM JEP (http://openjdk.java.net/jeps/188)
was to provide rigorous specs for the C/C++11 analogs introduced in
jdk9 VarHandles (http://openjdk.java.net/jeps/193; see current API at
http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html).

But we then discovered that doing this encountered some unsolved
research problems. Mainly that the current C/C++ model relies on rules
saying that programs with data races have no semantics, and does not
prohibit out-of-thin-air reads. And the existing JMM causality rules
that might help address this are known to be broken. Plus there are a few
minor-mismatch snags that do not seem hard to address, including that
plain Java variables are a little stronger than plain C/CC variables
(for example references cannot be word-torn), but weaker than atomics
in relaxed mode (they are not required to be coherent).

The hope (last year) was that progress would be made on these fronts, but
for the jdk-9 time frame, in the absence of a revised base memory model,
we should use careful English specs that convey intent that would someday
be backed up by a revised memory model.

There has been some progress on the underlying issues. See recent work by
Peter Sewell's group (http://www.cl.cam.ac.uk/~pes20/) on OOTA and
operational semantics, Allan Jeffrey (http://asaj.org/papers/lics16.pdf),
Jade Alglave (http://www0.cs.ucl.ac.uk/staff/J.Alglave/)
Viktor Vafeiadis (http://www.mpi-sws.org/~viktor/), and others.

So it is worth considering whether we can again move forward on
a major JMM revision. Comments would be welcome.

But in the mean time, we should do something to improve wordings that
Aleksey points out could mislead users and implementors in cases
where acquire or release access is optimized away or weakened
because it is thread-local, and so on. Minimally, we could add a
disclaimer that enables at least those transformations and optimizations
applying to volatiles.  Maybe just:

The ordering constraints imposed by getAcquire and setRelease are weaker
than, and  subsumed by those of getVolatile and setVolatile.

-Doug