Make load/store of 64-bit long and double atomic

[John Crowley]

All:

Some comments below, but I feel that at this time all of the points are on the table (and I’ve learned a few things!)

I’m glad to continue the discussion, but don’t want to waste anyone’s time so also OK to consider this thread closed - your choice.

Best to all,

John Crowley
Westport, CT
203-856-2396




> On Jul 13, 2016, at 4:20 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 12/07/16 23:42, John Crowley wrote:
>>> On Jul 12, 2016, at 8:35 AM, Andrew Haley <aph at redhat.com> wrote:
>>> 
>>> On 07/07/16 12:29, John Crowley wrote:
>>>> 
>>>> Right now, in a multi-threaded environment the developer must make
>>>> these volatile to ensure correct operation - which I would suspect
>>>> that 95% of Java developers do not realize. (I certainly didn’t for
>>>> over 20 years!)
>>> 
>>> After more discussion on jmm-dev, it's clear that
>>> VarHandle.{get,set}Opaque() will do exactly what you want: guarantee
>>> atomic accesses to longs and doubles without the overhead of volatile
>>> accesses.  I think that's enough for practical usage in Java.
>> 
>> Thanks for the info, but this just seems like we’re going in the
>> wrong direction.
>> 
>> Yes, it will technically work, and be slightly more efficient, but
>> we’ve managed to turn a simple get/put of a primitive into a
>> function call that will litter the code forever.
> 
> But is it that simple?  It's a racy access to a variable.  IMO it's
> not a terrible idea to give a reader warning that something odd is
> happening.  I wouldn't have thought that such accesses were very
> common in any code base.

You are correct in that observation. I’m mainly concerned that this is an inconsistency in the handling of primitives, and not needed in the world of 64-bit machines.

> 
>> Someone in the chain mentioned an experimental
>> -XX:+AlwaysAtomicAccesses flag, which sounds like it would do
>> exactly what is needed without requiring anything in the source.
>> 
>> Would really rather move towards making long and double operate the
>> same as object references and all other primitives instead of be
>> special cases.
> 
> Sure.  You're not the only one to have made this observation, and that
> opinion might eventually prevail.  However, there are 32-bit
> platforms, particularly in the embedded space, where long and double
> accesses would be significantly penalized.  If the worst problem is a
> little bit of clutter in the source code around racy accesses I reckon
> we're not doing that badly.

Understand, but think it is cleaner to say that the standard is atomic access but that a JVM flag exists to support the deprecated non-atomic access if required. Again, over multiple releases of Java and JVM.
> 
> Andrew.

Thanks for your insights,
John