VarHandles on non-int-sized fields and atomic operations

Martin Buchholz martinrb at google.com
Wed May 25 18:09:15 UTC 2016


On Wed, May 25, 2016 at 12:53 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> On 25 May 2016, at 01:15, Martin Buchholz <martinrb at google.com> wrote:

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

A*FU also provides API to weaken the normal semantics of volatile -
e.g. (the poorly named and specified) lazySet.  So it is already the
case that there is no global sequential consistent order in Java for
all memory operations on fields marked volatile!  (It's true that
there is no "volatile" for array elements)

The dynamic nature of VarHandle bothers me a little.  Static analysis
tools cannot discover fields being used with atomic operations with
certainty.  Even though in practice most uses of VarHandles will be to
fields declared "nearby".



More information about the core-libs-dev mailing list