[jmm-dev] jdk9 APIs

[Doug Lea]

On 08/21/2015 09:54 AM, Aleksey Shipilev wrote:
> On 08/20/2015 04:44 PM, Doug Lea wrote:
>> On 08/10/2015 02:22 PM, Doug Lea wrote:
>>      T getOpaque(Object owner);
>>      void setOpaque(Object owner, T val);
>
> My immediate reaction as the guy who wasn't participating in the
> original discussion: "Er, I don't like these at all".

With luck, this will be the universal reaction.
First you hate it, then you discover uncommon cases
in which you need it, then you begrudgingly accept it.
Maybe we can make a video.

For most people, the only thing to know about opaque is that
it fulfills the same role as the C cast-to-volatile escape
hatch, which is also justifiably unloved, but still used
for example in the Linux kernel.

> So, these seem
> similar to "relaxed", but only they are "hardware-relaxed", not
> "compiler-relaxed".

They basically say: even if other JMM rules would allow the read or
write to be optimized away, don't.  They feel like compiler-only
directives only because hardware never elides unbounded numbers
of reads/writes.

>
> It is also seems that (get|set)Opaque behavioral difference can only be
> observed under race,

Yes but use of VarHandle methods implicitly indicates "might be racy".
(So we don't need a separate annotation for this).

>
> So, if that is only to help the publication/consume cases, should we
> just rely on already implemented guarantees...

There is no sign that the series of special-cases will ever end.
We should try to understand and support explicit transformation
constraints when possible. But so far the record is not all
that great. So the only good pragmatic response I know is to
include opaque.

>>      T compareAndExchangeVolatile(Object owner, T expected, T val);
>>      T compareAndExchangeAcquire(Object owner, T expected, T val);
>>      T compareAndExchangeRelease(Object owner, T expected, T val);
>
> Um, I have a stupid question. What's the story with non-x86 processors
> here? Do we have any machines that do not have an explicit CAS, but only
> have LL/SC? Returning the failure witness does not seem doable with
> LL/SC-emulated CAS.

With LL/SC, you loop until either compare-failure with the LL'ed value
or success of the SC. So either way there is a unique answer.

-Doug