[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:
http://msdn.microsoft.com/en-us/library/system.gc.keepalive(v=vs.110).aspx
.  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.

Hans


More information about the jmm-dev mailing list