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

Hans Boehm boehm at acm.org
Tue Sep 2 21:07:56 UTC 2014

On Sun, Aug 31, 2014 at 7:04 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 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.
> ...
> 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.)
I thought we were focusing primarily on an annotation to declare fields
that are cleaned up by finalizers, so that accessing such fields inhibits
elimination of "dead" references.  I continue to believe that an API call
by itself will not fix the problem.

(One argument for keepAlive is that it's consistent with .NET:
.  But I'm not longer convinced we really want such a primitive at all.)

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

32-bit MIPS seems to be the problem case here.  It's unclear to me we can
do this in good conscience, though this may be a good time to announce that
we plan to eventually do it.  Since this property will not hold for value
types (or library calls with value-like behavior) or in other languages, I
don't feel very strongly about it either way.  I don't think it
fundamentally simplifies programmer's lives.  Presumably it would help some
numerical algorithms that rely on racy updates, but that's not exactly
Java's strength anyway.


More information about the jmm-dev mailing list