[jmm-dev] Make load/store of 64-bit long and double atomic

[Andrew Haley]

On 12/07/16 03:21, David Holmes wrote:

> This is not a hotspot issue but a Java programming language issue.
> Hotspot would never provide a flag that changes the Java programming
> language semantics. The performance impact of all-accesses-are-
> atomic on 32-bit systems is considerable

Not necessarily.  There are significant performance implications on
some 32-bit systems, but by no means all.  And such 32-bit systems are
getting rarer -- IMVHO.

> so as long as we support 32-bit I don't see this happening
> (regardless of what may be discussed on jmm-dev). It would be
> unconscionable to have different semantics on 32-bit and 64-bit so
> that is not an option either.

I wonder if a better solution to this might be to make
VarHandle.{get,set}Opaque atomic on all primitive types.  This gives
us a way to get atomic operations on 32-bit machines without the
overhead of volatile accesses.  Being able to read a 64-bit counter
atomically is very useful.

C++ says:

[ Note: Atomic operations specifying memory_order_relaxed are relaxed
with respect to memory ordering.  Implementations must still guarantee
that any given atomic access to a particular atomic object be
indivisible with respect to all other atomic accesses to that
object. — end note ]

But Java says:

Unless stated otherwise in the documentation of a factory method, the
access modes get and set (if supported) provide atomic access for
reference types and all primitives types, with the exception of long
and double on 32-bit platforms.

I wonder if this divergence between Java and C++ is deliberate.  It
seems wrong to me.

Andrew.