[jmm-dev] Enforcing access atomicity (benchmarks)

[Aleksey Shipilev]

On 02/14/2014 05: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
> 
> 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.

I would *really* like the feedback from ARM folks on this, because the
performance experiments need a properly functional and correct access
code for all the platforms. While we haven't found the empirical
evidence those we have now are broken, it might be just the luck?

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

+1. Having written some sophisticated high-performance code in Java, I
am excited about the access atomicity guarantees, when you are dealing
with the eventually-consistent code. I would be more relaxed about
long/double exception for ordinary load/stores, as long as there is a
way to achieve *only* the access atomicity, without burdening myself
with the memory semantics around volatiles. That's one of the things my
post was trying to showcase: the add-on of volatile semantics
significantly increases the costs comparing to "just" the atomic access.

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

I think there is a slight bias in the way we ask the question.

We call it "drop the access atomicity exception", while we really should
discuss "requiring the access atomicity for 64-bit types as well". The
argument about value types surely fits the former discussion, because
why dropping the exception, if we are about to reintroduce it? The
latter one is more interesting: where we draw the line about what
accesses are atomic, and what are not.

-Aleksey.