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

Andrew Haley aph at redhat.com
Wed Jul 13 08:20:18 UTC 2016


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.

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

Andrew.


More information about the hotspot-dev mailing list