[jmm-dev] Enforcing access atomicity (benchmarks)

[Doug Lea]

On 02/10/2014 02:18 PM, Aleksey Shipilev wrote:
> Here you go, the early estimates for enforcing access atomicity:
>   http://shipilev.net/blog/2014/all-accesses-are-atomic/
>
> Go straight to "Conclusion" for TL;DR summary. In short, in 2014, most
> platforms are already able to pull off 64-bit accesses

Thanks! This prodded me to further investigate a few issues:

Are there ANY platforms that do or could otherwise support JVMs
and for which there is no reasonable way to conform?

The answer depends on how far you want to stretch "reasonable"
(worst case, JVMs could insert locks), but some 32bit versions
of PPC and MIPS seem problematic. Also, it might be the case that
floating-point (double) on ARM (even ARMv8) requires special handling.

The answer also depends on what you mean by "JVM".
Java "ME" (M for Mobile) specs have not kept pace with
the "SE" specs that we've implicitly been targeting.
Most but probably not all problematic cases are only
relevant for ME anyway.

Backing up, the main reason for contemplating this is spec
simplification. Getting rid of non-obvious rules and special
cases one by one may eventually result in a model/spec that
overcomes the "you are not expected to understand this"
reputation of the JMM among developers.

An argument for not simplifying is that programs shouldn't
have any races where non-atomicity would be observable anyway.
It's a pretty good argument, although not very convincing
to some developers writing code for monitoring and profiling,
as well as some numerical heuristics. They often could care less
about race-freedom so long as they arrive at empirically
acceptable approximations of reality. And in any case,
the presence of potential non-atomicity causing reads of a
long or double to rarely take crazy/wild values only
on uncommon platforms is not a very nice way to alert people
of problems.

Another argument for not simplifying is that (as Brian mentioned)
we expect JDK9 to support wider value types of some sort;
surely including those for which no processor guarantees
atomicity.  So there will always be atomicity disclaimers of
some kind somewhere.

Across these concerns, it seems that resolving this issue is
mostly a policy decision. I welcome any more compelling
arguments on either side than I listed above. Without
them, this might not become settled until (much) later when
canvassing broader community input.

-Doug