[jmm-dev] Enforcing access atomicity (benchmarks)

[David Holmes]

On 14/02/2014 11:49 PM, Doug Lea wrote:
> 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.

Not just double but also float. The ARMv8 spec not only doesn't provide 
single-copy atomicity for 64-bit FP values but it even rolls back the 
32-bit guarantees, for FP, to only providing byte-level single-copy 
atomicity! So in theory a float/double can be loaded/stored one byte at 
a time!

Perhaps our ARM folk could comment on this as we've been used to getting 
32-bit atomic accesses on 32-bit platforms for an awful long time now.

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

SE Embedded is impacted by this.

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

I think the non-atomic treatment of long/double unless volatile is so 
isolated in the memory-model, and so stand-alone and simple, that 
removing it would be imperceptible in the overall complexity of the JMM.

David
------

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