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

[Aleksey Shipilev]

On 06/17/2016 11: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. But in reality,
>> they are weaker than fences, because optimizers are not obliged to
>> introduce barriers around the operation to get the needed semantics.
> 
> I've read this several times now and I still do not understand it.
> Release and acquire are well-defined terms in the industry, 

I dare anyone to produce the consistent industry definition of "acquire"
and "release" :)

> and I can't think of any great reason to add more words like yours,
> which seem to make things even more confusing than they were. The
> wording which is there seems to me to be accurate, at least, as a
> description of release and acquire.

That might be true if you take the *hardware* definition of
acquire/releases, where prohibiting reorderings is surely a plausible
semantics. (There is no telling if CPU vendors will some day describe
their hardware memory models with abstract rules, like high-level
languages do)

But the trouble is with allowing software optimizations, as volatile
example shows. A runtime should be able to elide barriers around
volatiles, if this elision does not violate JMM. In fact, it is
trivially doable when optimizers realize they are dealing with
thread-local volatile ops (e.g. on a non-escaped object, or in
constructor). This is what my original example shows.

Now, VarHandle's acquire/release can be seen as further _relaxations_ of
volatile semantics, when you give up sequential consistency for better
performance. Therefore, the barriers around acquire/releases should also
be elide-able. Therefore, specifying VarHandle's acquire/release with
reoderings is odd.

You can certainly specify that acq/rel inhibit reordering, but this way
we face even a weirder inconsistency. It means that volatiles are *more
optimizeable* than acq/rel, which defeats the purpose of having acq/rel
to begin with!

HTHS,
-Aleksey