[External] : Re: Proposal: java.lang.runtime.Carrier

[John Rose]

On 7 Mar 2022, at 16:07, forax at 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