Fwd: nullable-inlined-values on the heap

[Brian Goetz]

>> If this is possible, maybe Valhalla's Java could have a user-model 
>> like this:
>
> You should probably start with what problem you are trying to solve.

The poster offered the following clarifications:

> The problem it's trying to solve is to remove the .val and .ref 
> operators/knobs/concepts from the user-model without any loss of 
> performance or loss of control over nullability, zeroness or 
> atomicity. In other words, the objective is to take Kevin's 
> ref-by-default idea one step further.
>
>
>     In theory, we could construct the union type int|Null, but this
>     type doesn't have a practical representation in memory, ...
>
>
>
> Would it be possible to have a value-class give rise to these 3 
> hidden/runtime-only companion-types on the heap:
>
> RefType  - reference to a value-instance or no-reference (null)
> ValType  - inlined [value-instance-fields]
> ValType? - inlined [nullability-boolean + value-instance-fields]
>
> Then, the runtime could transparently choose between RefType|ValType 
> for non-nullable variables or between RefType|ValType? for nullable 
> variables, depending on hardware, bitSize, zeroness and atomicity 
> constraints, as explained by the ternary expression in my previous 
> email. Of course, since ValType? has a higher bitSize than ValType, 
> nullable values will be less likely to be inlined. But still, the 
> point is: could nullable values sometimes be inlined on the heap as 
> opposed to never being inlined.
>
>
>     In theory, we could construct the union type int|Null, but this
>     (...) drags in all sorts of mismatches because union types would
>     then flow throughout the system.
>
>
>
> Is my 3-companion-types solution a real union type? Sure, I am 
> suggesting two sort-of-unions:
>
> RefType|ValType  - for non-nullable value-class variables
> RefType|ValType? - for nullable value-class variables
>
> However, to the user, both types in each union represent the same 
> exact value-set.

My comments:

Except the model proposed actually had _more_ knobs than where we are 
now: just as many declaration-site knobs (no identity, tearable, 
zeroable), and more use-site knobs (atomic, nullable.)

Reading between the lines, what I think is going on here is: ".val is 
ugly, can we find a way to spell it !, so we can pretend there aren't 
really two things."

And I totally get the desire to do this!  But I don't think these are 
the droids you are looking for.  The overwhelming lesson of Valhalla has 
been: every time we try to associate something with nullity (identity, 
reference-ness, flattening, atomicity, etc), it turns out to be a mistake.

>
> Would it be possible to have a value-class give rise to these 3 
> hidden/runtime-only companion-types on the heap:
>
> RefType  - reference to a value-instance or no-reference (null)
> ValType  - inlined [value-instance-fields]
> ValType? - inlined [nullability-boolean + value-instance-fields]

I think there are at least two tails wagging this dog here -- the syntax 
tail (I want to say ?/!, not .ref/.val) and the performance tail.  Note 
that the RefType and ValType? in this breakdown are semantically 
identical!  The only difference is the assumed performance model -- 
"reference vs inlined."  But we *already* can do significant flattening 
on the .ref types (calling convention and locals.) If we could achieve 
the kind of inlining you want for ValType? in the heap, we would just do 
it for RefType too, and we wouldn't need a third thing.  So this 
breakdown is just making it needlessly more complicated for no benefit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220701/7a77ffbc/attachment.htm>