[jmm-dev] jdk9 APIs

[Doug Lea]

On 08/24/2015 08:01 PM, Hans Boehm wrote:
> Some more comments:

Thanks!

>
> I think the getAnd() operations also need to specify that the load part is
> volatile, so that an earlier volatile store synchronizes with the call.

Thanks; fixed.

>
> The "reordering"-based specifications are extremely problematic.  They give no
> hint that, for example, IRIW can produce non-SC results with LoadLoad or Acquire
> fences.  But I think that has to be allowed for anything other than fullFence()
> to be useful.

Yes. It is hard to be clear without accidentally revising the JMM.
We once (in previous efforts) came up with some wording to help
explain. I'll look for it and try to adapt.

>
> Note that the use of "Relaxed" here is seriously weaker than in C & C++.  It
> doesn't promise cache-coherence.  That's a sufficiently serious difference that
> I'm not sure I would use the same word.

And plain (non-volatile, non-final) Java vars are also not exactly the same
as in C/C++. I and others have gone back and forth on using "getPlain" (etc)
vs "getRelaxed" here. Using getPlain sounds odder but might be a better choice.

I suppose we could even have both getPlain and getRelaxed, but it seems
better just to add an explanation somewhere about how to obtain coherence
if you need it.

>
> Is it intended to be possible to apply these methods to built-in types like
> long?  If so, does Relaxed provide word-tearing guarantees?

Yes. This should be indicated in class-level docs that don't
currently exist because NotReallyVarHandle doesn't really exist :-)
We had discussed and seemed headed to removing this disclaimer
for all Java primitive vars, but for now we can at least do so for
those accessed with VarHandles.

> reachabilityFence:
>
> "regardless of any prior actions of the program that might otherwise cause the
> object to become unreachable" doesn't sound right to me.  It really revokes the
> compilers license to "misoptimize" the program normally given by 12.6.1:
>
> "Optimizing transformations of a program can be designed that reduce the number
> of objects that are reachable to be less than those which would naively be
> considered reachable."
>
> The real guarantee seems to be that reachabilityFence(ref) happens before ref is
> finalized or added to a java.lang.ref queue.  Can we include that in its definition?
>

Will do; thanks,

>
> Presumably it's too late to add an annotation?

Not too late, but a separable effort that I'd like to encourage people
to undertake. We laid the groundwork on this list last August.
Carrying it out seems to need involvement of compiler and IDE developers.

-Doug