[jmm-dev] jdk9 APIs
dl at cs.oswego.edu
Wed Aug 26 12:01:34 UTC 2015
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.
More information about the jmm-dev