Null support for inline class reference projections through bitmaps

Christian Beikov christian.beikov at
Sat Dec 5 11:12:27 UTC 2020

Forget section 1. I thought about this again after getting some sleep, and
I now realize that a default value for value projections is necessary for
e.g. collections to be usable with these types.

Have you decided yet if inline classes are allowed to specify custom
default values?


Christian Beikov <christian.beikov at> schrieb am Sa., 5. Dez. 2020,

> Hi,
> up until now I was mainly reading mailing list topics and watching Youtube
> videos about Valhalla, but since default values for inline classes were
> recently discussed again in the "Embrace nulls" topic I wanted to
> discuss/share an idea I had.
> Since there are types like e.g. LocalDate which would like to be inline
> classes but don't have a good default value, I was thinking about how the
> default value for value projections could be avoided and null could be used
> as default for reference projections efficiently.
> 1. How to avoid the need for default values for value projections
> As far as I understood, default values are only relevant in the following
> contexts:
> 1.1. When accessing uninitialized fields of a value projection inline
> class type, one can observe the all zero bit value.
> If we could disallow read access to such uninitialized fields and require
> explicit initialization through the verifier, the VM could safely continue
> using the all zero bit pattern for object allocation.
> 1.2. After value projection array creation, array elements are initialized
> with default values.
> What if the creation of value projection arrays is only allowed for inline
> classes that have a default constructor(in the newarray bytecode the VM
> initializes the cached default value as created by the default constructor)
> and through an intrinsic method e.g. <any T> T.val[] Arrays.unbox(T.ref[])
> that does null checks?
> Am I missing something or would these restrictions make default values for
> inline classes optional? Could the fact that a default constructor exists
> be used to model whether the inline class name should refer to the value or
> reference projection by default?
> 2. Support nulls for reference projection (efficiently?)
> Maybe you already work on something like that, but so far, I was of the
> impression that reference projections for inline classes wouldn't be that
> much better than normal reference types, so I thought about how reference
> projections could be modeled efficiently.
> The general idea I have is to introduce a bitmap to track the nullness of
> all (transitive) reference projections within a container like an array or
> object.
> Here a quick example to showcase what I mean:
> record NormalClass(Value1.val v1, Value2.ref v2){}
> inline record Value1(long l){}
> inline record Value2(Value.ref v1, long l2){}
> The transitive reference projections in NormalClass are v2 and v2.v1.
> Similarly, for Value2.ref[] nullness must be tracked for the element
> itself and element.v1.
> For types with a size + bitmap size <= word size, the bitmap could be
> made a part of the word for the value. Bitmaps for bigger types would be
> merged together in a container. A merged bitmap would track nullness for
> reference projections within a cache line boundary such that every cache
> line has a merged bitmap for the elements on the cache line.
> This bitmap approach should be applicable in all cases, for local
> variables, fields and arrays.
> Is this bitmap approach for nullness tracking of reference projections
> something you are already doing? If not, why and what other approach are
> you using then?
> Regards,
> Christian

More information about the valhalla-dev mailing list