[jmm-dev] jdk9 APIs

[Doug Lea]

On 08/25/2015 01:09 PM, Hans Boehm wrote:
> On Tue, Aug 25, 2015 at 6:22 AM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
>     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'm still torn between odd-soundingness vs reducing chances of confusion.
Does anyone else have an opinion?

>     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.
>
> I think that's hard to do portably, right?  Acquire/release should work since they
> are defined analogously to C++, which requires coherence.  But they're clearly
> substantial overkill, e.g. on Power or ARMv8 (or v7 without the erratum).

These seem to be variants of the issues in our write-combining discussion
last week. And maybe not even variants: Of the cases I can recall
being discussed wrt per-variable coherence, I'm not sure which of
the choices of setOpaque, setRelease, releaseFence, or storeStoreFence
(with symmetric choices on the load side) people had in mind.

>     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.
>
> I now think that earlier discussion was premature, but it makes sense
> to remove the disclaimer here.  Removing the disclaimer in general is expensive
> and probably not feasible on 32-bit MIPS and some older ARM processors.
>

OK. In fact, this (banning word-tearing only via VH) might not a bad move
even when we do revise JMM/JLS.

-Doug