P4
The AccessAPI provides a number of method to atomically access a field in a heap allocated object. All the current supported types for the data being accessed are either Java primitive types or the reference type (oop).
Values types, especially as defined in JEP 401, need to store a null marker in addition of their normal content when they are stored in a flattened form. This is not an issue for value types containing only primitive type fields, the JVM uses the AccessAPI of the primitive type with a size equals or bigger than the size of the value. But this is an issue if the value contains a reference because it requires special handling by the GC.
This limitations currently prevents the flattening of value classes like Optional<T>.
If the AccessAPI could be extended with methods providing atomic access of values containing an oop plus a primitive, this would enable more heap flattening.
Support for atomic operations is currently limited to 64 bits or smaller chunks of memory, so the number of possible layouts to support is also limited:
<compressed_oop><32bits of primitive data>
<32bits of primitive data><compressed_oop>
<compressed_oop><compressed_oop>
The last case would not be used for nullable flat values but could be used later when null-restricted fields are supported by the language.
Values types, especially as defined in JEP 401, need to store a null marker in addition of their normal content when they are stored in a flattened form. This is not an issue for value types containing only primitive type fields, the JVM uses the AccessAPI of the primitive type with a size equals or bigger than the size of the value. But this is an issue if the value contains a reference because it requires special handling by the GC.
This limitations currently prevents the flattening of value classes like Optional<T>.
If the AccessAPI could be extended with methods providing atomic access of values containing an oop plus a primitive, this would enable more heap flattening.
Support for atomic operations is currently limited to 64 bits or smaller chunks of memory, so the number of possible layouts to support is also limited:
<compressed_oop><32bits of primitive data>
<32bits of primitive data><compressed_oop>
<compressed_oop><compressed_oop>
The last case would not be used for nullable flat values but could be used later when null-restricted fields are supported by the language.