Value types and access atomicity
Aleksey Shipilev
shade at redhat.com
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:
https://github.com/openjdk/valhalla/pull/427
--
Thanks,
-Aleksey
More information about the valhalla-dev
mailing list