On 7 Mar 2022, at 16:07, fo...@univ-mlv.fr wrote:
Not necessarily, while java.lang.Object appears in the bytecode a JIT like c2 propagates the real type of the constants (here empty() is typed with the type of the carrier not with java.lang.Object at runtime) so introducing null may introduce some stupid nullchecks.
Null checks are usually cheap, because they are usually done implicitly in parallel with the first access that requires a non-null value. This works for true references, but not scalarized values.
We want scalarized values, of course. So what I might worry more about here is forcing the JVM to buffer the value object on the heap because of possibility of null. (B3 primitives/bare values are designed to make that less likely.) I think even here null is OK, because *all* B2 types are *both* nullable and scalarizable (if not null), so it is very likely the JVM is going to do extra work to adjoin (the technical term is “cram in”) a null representation into the scalarized representation, using an extra register if necessary.
Bottom line: Nullability doesn’t concern me here, since I assume we are going to continue to work hard (because of B2 value types like ju.Optional) to support both nullability and scalarization.
— John
