Nullness markers to enable flattening

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Kevin Bourrillion" <kevinb at google.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "daniel smith" <daniel.smith at oracle.com>,
> "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Wednesday, February 8, 2023 10:10:14 PM
> Subject: Re: Nullness markers to enable flattening

>> 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.

I would say, Valhalla has two objectives, providing a more compact memory representation aka B3 is one, having a better escape analysis aka B2 is another. 

Now, B2 and B3 are from the VM POV, it does not have to leak too much in the user model, we can have value class and zero-default value class at the user level. 
I kind a like the progression "value class", "zero-default value class", "atomic zero-default value class" that intuitively goes toward better performance at the expense of a non-usual semantics. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230208/0d875b5e/attachment-0001.htm>