Make load/store of 64-bit long and double atomic
John Crowley
jdcrowley at gmail.com
Tue Jul 12 22:42:14 UTC 2016
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.
More information about the hotspot-dev
mailing list