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

[David Holmes]

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.

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

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.

Cheers,
David

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