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

[John Crowley]

John Crowley
Westport, CT
203-856-2396


David, 

> On Jul 12, 2016, at 11:53 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> John,
> 
> I think the point is that the Java language specification for this is not likely to change any time soon (certainly not 9, probably not even 10), and when it does change it will be to accommodate future constructs like value types - which raise the question of whether uniform atomic access should extend to types larger than 64-bit.
> 

Agree that nothing will change for several Java releases.

Just feel that this is an historical inconsistency, the future world will be almost entirely 64-bit architectures, and every app will be multi-threaded, so that handling the increasingly rare 32-bit environment at the JVM level is a cleaner approach.

Understand that value types may add some additional feedback to this discussion, so some experience there will be good. 

> Meanwhile if you want to experiment there is the VM flag.

Yes, this does look good.

> 
> Additionally the VarHandle API provides an extra-linguistic mechanism for defining and applying access modes beyond those provided in the Java programming language. They are verbose to write but will be (JIT) compiled into direct access code.

Got it - just hate to clutter up the source code.

> 
> Cheers,
> David


Thanks for the insights,
John
> 
> On 13/07/2016 8:42 AM, John Crowley wrote:
>> 
>> 
>> John Crowley
>> Westport, CT
>> 203-856-2396
>> 
>> 
>> 
>> 
>>> On Jul 12, 2016, at 8:35 AM, Andrew Haley <aph at redhat.com> wrote:
>>> 
>>> On 07/07/16 12:29, John Crowley wrote:
>>> 
>>>> Would like to make a suggestion re the JVM and non-atomic load/store
>>>> for long and double values since both are 64-bit.  (Sec 17.7 of the
>>>> JLS version 8 - have not been able to find a JLS V9 yet). Did some
>>>> searching through JSRs and mailing lists, but did not see this
>>>> addressed - please send me a link if it has been and I just missed
>>>> it.
>>>> 
>>>> 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.
>>> 
>> Hi Andrew,
>> 
>> 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.
>> 
>> IMHO if not already, then certainly within the next 10 years, 99% of Java code will execute on 64-bit platforms. It would seem better to migrate the language specification and JVM towards the cleanest possible code in that environment rather than add code everywhere in case of the 1% situation. Yes, the 1% case must be supported, but it can be with existing language constructs (volatile, {get,set}Opaque, AtomicLong/Double), or the JVM option as suggested [which keeps the source code clean].
>> 
>> 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.
>> 
>> John
>> 
>>> Andrew.
>>