Nullness markers to enable flattening

[Brian Goetz]

> To get my stance (that you already know) onto the list: for a nullable 
> type, null is immeasurably *better* than just a "sensible default"; it 
> is *no default at all*. Information is simply missing, never guessed 
> at. Null is a wonderful thing (it's only a null-oblivious type system 
> that makes us think it isn't).

Yes, though we have to be careful to not push this argument too far -- 
if we do, it leads back to "B1 is all I need", and we can all go home.

The reason B1 is not sufficient is that, absent representational heroics 
(such as using type-specific slack bits to encode null), it basically 
forces an indirect representation, losing the flatness and density that 
Valhalla aims to give us.  And the same is true for B2, but less so.  B2 
gets half the benefit; by giving up identity, it gets flattening on the 
stack (calling convention optimization.) That's good, but if that's all 
we got, it wouldn't be so great.

B3 is what it is because the VM has a very strong bias towards 
initializing to zero.  If the zero-bits are part of your domain and an 
acceptable default, then great, you have the option to fully flatten.  
But if the zero bits are not, then we have no efficient and safe VM 
representation for non-nullable B2; either we choose indirection (giving 
up performance) or we use Q types and risk the zero leaking (giving up 
safety).  B1 doesn't have this problem because what leaks when erasure 
gets fooled is null, which fails fast when you try to use it, rather 
than leaking a value that looks like it might be a valid value, but 
which the constructor would never have generated.

So this is why Valhalla distinguishes B3 -- because its the kind of 
value that we can give the full-flat treatment to.  And while there may 
be more use cases that are suitable for B2 than B3, there are likely 
more *instances* of the B3 values -- because we will allocate huge 
matrices of Complex or HalfFloat.

So we can't say "B2 is all we'll need", because B3 is where the 
performance that motivated Valhalla comes from.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230208/7ca709be/attachment.htm>