[jmm-dev] jdk9 APIs

Hans Boehm boehm at acm.org
Tue Aug 25 17:09:43 UTC 2015


Thanks!

A couple of further responses:

On Tue, Aug 25, 2015 at 6:22 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 08/24/2015 08:01 PM, Hans Boehm wrote:
>
>> ...
>
> 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.

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


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

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.

Hans


More information about the jmm-dev mailing list