[jmm-dev] jdk9 APIs

[Aleksey Shipilev]

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". So, these seem
similar to "relaxed", but only they are "hardware-relaxed", not
"compiler-relaxed".

Doesn't this depart from having a memory model covering both software
and hardware behaviors? Doesn't that hurt cross-platform compatibility?
Inviting users to use the public APIs that perform functionally
differently on different hardware is silently leading them into the
platform lock-in. An explanation "do whatever hardware does", while
looking more appealing, means the same.

It is also seems that (get|set)Opaque behavioral difference can only be
observed under race, but AFAIU that can be differentiated against the
unlucky timing only when some other causal non-synchronization
relationship holds (e.g. during object publication).

So, if that is only to help the publication/consume cases, should we
just rely on already implemented guarantees for final fields (and
possibly revisit the idea of making all initialization stores "final",
and then emit the barrier implicitly -- thus covering the corner case of
volatile fields initialized in objects), rendering the producer-consumer
problems a moot for a while?


>     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.

Thanks,
-Aleksey