Value types and access atomicity

Aleksey Shipilev shade at
Tue May 25 17:27:54 UTC 2021

On 5/25/21 6:14 PM, Paul Sandoz wrote:
> What you observe is the proposed default behavior, with the following to enable atomicity: - mark
> the field as volatile (dunno if the implementation currently supports this); and
Right. Adding "volatile" indeed restores the access atomicity, like it should for longs/doules.

> VHs will require some spec/impl adjustment. Atomic VH access to a plain field of non-atomic
> primitive class is gonna be problematic (fail? or global lock, yuck!).
Yes. I would expect that doing VH.getOpaque over primitive-class-typed field gives me atomicity 
back. It would be sad to sacrifice nearly the only guarantee that opaque mode actually provides...

> I believe the implementation technique at the moment is to not flatten volatile fields. I am not
aware of any attempts to optimize for say smaller sizes (e.g. seq locks), or those that fit in 64 bits.

Right. So -XX:+AlwaysAtomicAccesses can stay a while and be plugged to the code that avoids 
flattening volatile primitive fields:


More information about the valhalla-dev mailing list