-
Bug
-
Resolution: Unresolved
-
P4
-
repo-valhalla
The fix for JDK-8351569 redefines which access modes are supported by value var handles. For CAS to be supported on a field var handle the field must be either:
* non-nullable
* volatile
* have a type of a non-weakly consistent value class
(similar restrictions apply to array access). In other words, CAS operation will either target values with non-flat layout or with atomic flat layout. In the latter case, we expect the size of the flat layout not to exceed 64 bits.
The TestIntrinsics test has test cases for atomic operations invoked on value types (via the Unsafe API). However, these test cases do not conform to the restrictions outlined above. For instance, `test63` attempts a CAS on a non-volatile, null-restricted field whose type is a weakly-consistent class. As such, calling `compareAndSetFlatValue` on such a field will result in undefined behavior, as the flat layout for this class doesn't fit in 64 bits.
* non-nullable
* volatile
* have a type of a non-weakly consistent value class
(similar restrictions apply to array access). In other words, CAS operation will either target values with non-flat layout or with atomic flat layout. In the latter case, we expect the size of the flat layout not to exceed 64 bits.
The TestIntrinsics test has test cases for atomic operations invoked on value types (via the Unsafe API). However, these test cases do not conform to the restrictions outlined above. For instance, `test63` attempts a CAS on a non-volatile, null-restricted field whose type is a weakly-consistent class. As such, calling `compareAndSetFlatValue` on such a field will result in undefined behavior, as the flat layout for this class doesn't fit in 64 bits.
- relates to
-
JDK-8351569 [lworld] Revisit atomic access modes in flat var handles
-
- Resolved
-