VarHandles on non-int-sized fields and atomic operations

[Paul Sandoz]

> On 24 May 2016, at 02:55, Martin Buchholz <martinrb at google.com> wrote:
> 
> Another way to look at it:  We have an existing field
> 
> boolean closed;
> 
> which should be updated using CAS for correctness, but currently is not.
> I should not have to change the type of the field to int just so that
> I can get something that is CASable.

I think you would have to qualify that field in such a manner to inform the VM how best to layout the memory optimally for expected operations on that field.

At the moment we don’t have such a qualifier:

  “this is a boolean but i don’t care about size,
   please use what ever bit size and alignment is needed
   so i can perform hardware-based atomic operations on it”

As Aleksey said VarHandle is low-level. It can replace the use of Unsafe within AtomicBoolean. If you currently want to achieve what AtomicBoolean does without the boxing you need to use an int field and operate on it directly.

It seems quite possible to expose VarHandle field views covering an int for the shorter types boolean, byte. char and short. Internally those types are widened to int for basic signatures so i think it’s just a matter of rewiring to the VH int field support with adjusted method types. (The boolean case may require a little more care given the disparity between Java source and byte code.) However, i am not sure that is very helpful.

I would be reluctant at this point (and we were already reluctant) to investigate sub-word atomic ops, and the implications that might have for guarantees/locking/tearing/performance etc.

Paul.