RFR 8151198: VarHandle factory-specific exceptions

[Hans Boehm]

I didn't previously have the impression that get/setOpaque was analogous to
just C/C++ volatile.  C volatile officially has nothing to do with threads
and does not prevent undefined behavior for data races.  It does not in
general guarantee single-copy atomicity.  (It can't, since it can be
applied to arbitrary structs.) Whether or not it guarantees any sort of
ordering (e.g. with respect to IO devices) is unclear if you go by the
spec. Most platforms have decided it does not.  But this is not 100%
consistent and, in my personal opinion, it's not the most natural reading
of the standard. It arguably doesn't guarantee cache coherence, i.e. single
variable ordering, since it's unrelated to threads.  (This isn't the
cleanest state of affairs, or one to be emullated.  It's also probably not
fixable, since each platform does generally have a well-defined notion of
what "volatile" means; they're just not entirely consistent.)

My prior impression was that Opaque was intended to be similar to a C++
memory_order_relaxed access to a variable that is declared as both atomic
and volatile, with the unordered interpretation of C++ "volatile".  I.e.
accesses are guaranteed single-copy-atomic (even for long and double), must
result in a sequence of load and store instructions that exactly reflect
the naive semantics (a property NOT guaranteed for C++ memory_order_seq_cst
accesses or Java volatiles, but guaranteed for C volatiles). Accesses are
guaranteed to be "cache coherent", i.e. access to a single variable appear
to occur in a single total order.

I am not sure that my prior impression reflects the true intent. But I'm
currently quite confused as to what the intended semantics of "opaque"
really are.  The spec eeds to be clearer about single-copy atomicity and
cache-coherence properties.  And probably about the fact that the
guarantees here are incomparable to volatile accesses, i.e. stronger in
some respects, and weaker in others.

On Fri, Apr 8, 2016 at 8:59 AM, Martin Buchholz <martinrb at google.com> wrote:

> On Fri, Apr 8, 2016 at 7:40 AM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com> wrote:
> > On 04/08/2016 03:51 PM, Paul Sandoz wrote:
> >>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/webrev/
> >> <
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/webrev/
> >
> >
> > I agree with updates.
> >
> > But have more comments on C/C++ @apiNote-s. Would you like to address
> > them in follow-ups? Notably, getVolatile may be also marked analogous to
> > memory_order_seq_cst, and get/setOpaque may be marked analogous to C/C++
> > "volatile"-s. And CAS/CAE memory semantics can also be spelled out in
> > terms of std::memory_order.
>
> I agree with Aleksey.
>