VarHandles on non-int-sized fields and atomic operations

[Paul Sandoz]

> On 25 May 2016, at 01:15, Martin Buchholz <martinrb at google.com> wrote:
> 
> More high-level observations on low-level operations:
> 
> We already sort-of have an existing field qualifier for atomic: "volatile" !
> It is already the case that e.g. volatile long is atomic while
> unadorned long is not.
> But atomics without CAS make us sad, so we're adding them.
> Also, by analogy, Atomic*FieldUpdaters must refer to a volatile variable.
> It seems not unreasonable to require that VarHandles also refer to a
> volatile field.
> 

We wanted the flexibility to perform “normal" plain access against other accesses using a VarHandle, of course that requires very careful use. Furthermore, other operations anyway override that of the volatile semantics.

(Relatedly, there is no qualifier on the components of an array.)


> If a field is declared
> volatile boolean;
> then the VM should ensure not only that it can be reasonably
> efficiently updated using ordinary read/write as is already the case
> but also that it can be reasonably efficiently CAS'ed, and that may
> mean giving it 32 bits instead of 8 on some platforms.  But it would
> be a VM implementation detail.
> 

That flexibility may be required for SPARC [*], though i don’t know how much work would be required to support such platform Object specific layouts.


> It would be even nicer if the field qualifier was literally "atomic",
> but I don't think that is going to happen.  The best we can hope for
> is:
> 
> "volatile" is how you spell "atomic" in Java.

That is a reasonable assumption under the circumstances, although i don’t like the way volatile conflates atomicity and memory ordering guarantees and arguably what you propose does adds to the conflation, since int field access is already atomic.

I would still prefer the flexibility of not requiring a field covered by a VarHandle to be declared as such, even if volatile is conflated further (as mostly an implementation detail) to imply efficient CAS operations can be performed, perhaps at the expense of using more memory.

Aleksey did some analysis to indicate we might be able to achieve access atomicity (not conflated with being able to perform an efficient CAS) by default without qualification for all types:

  http://shipilev.net/blog/2014/all-accesses-are-atomic/

and you can even use an experimental flag -XX:+AlwaysAtomicAccesses and try it out.

Paul.

[*] IIUC SPARC has just 32/64bit CAS operation. ARM has byte/short LL/SC instructions.