[jmm-dev] Non-core-model issues status

Doug Lea dl at cs.oswego.edu
Sun Aug 31 14:04:55 UTC 2014


By request, here's a summary of where I think we are on issues other
than reformulating the core model. None of these are final or
definitive, and new ideas are always welcome.

1. We will spec (outermost) constructors to perform release on exit.
The spec will not otherwise include specs on final fields, although
there should be JLS wording to explain consequences; i.e., as one case
of reads of fields via a reference read for the first time by a thread
being dependent on that read.  We don't expect to explicitly support
any further analogs of C++/C11 consume mode (which this may be seen as
a special case of).

2. We introduce and spec a reachabilityFence(Object x) method, and add
wording about it in JLS sec 12.6. Further suggestions for doing more
are still welcome. (Also, the method name is still up for grabs.
Except that the name "keepAlive" is known to be too confusing
to consider.)

3. I don't think we came to a consensus about guaranteeing
non-volatile 64bit (long, double) atomicity. There will still be 32bit
platforms without reasonable implementations around for years. But
even now they account for a tiny percentage of platforms. So even if
atomicity is not guaranteed, programmers may increasingly act as if it
were, because even high-quality software tests never fail in practice
unless run on uncommon processors. If this were C, we might add a
user-visible analog of JVM-internals that reveal whether a type is
atomic, and rely on programmers to use it. But I don't think we can
get away with this in Java.

4. We will more uniformly support and spec analogs of C++/C11 moded
access on fields, array elements, and statics. I had initially
proposed doing this as a small syntactic extension in JEP193. But I
think everyone has now settled on instead introducing "VarHandles",
which are more language-agnostic; basically serving as lighter, more
broadly applicable, and more efficient variants of
AtomicXFieldUpdaters that exploit and extend JDK8 MethodHandles. Paul
Sandoz has been working on this within the Valhalla project, and has
committed a preliminary version (that I haven't used yet). (See
http://mail.openjdk.java.net/pipermail/valhalla-dev/2014-August/000111.html)
They are still not fully spec'ed, and probably cannot be until core
model settles. But given precedent in C++/C11, I don't expect major
obstacles in doing so.

Also, not-very-relatedly: I see that Jade Alglave's TOPLAS paper on
Power (and ARM) is now available (see
http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/toplas14.pdf among
other links from http://www0.cs.ucl.ac.uk/staff/j.alglave/).  Even
those who don't want to know gruesome details might want to browse to
get a better sense of the intentions of processor architects mentioned
here and there in the paper.

-Doug




More information about the jmm-dev mailing list