The storage hint model

[forax at univ-mlv.fr]

> From: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "daniel smith" <daniel.smith at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Wednesday, July 27, 2022 1:57:06 PM
> Subject: Re: The storage hint model

> Remi,
> IMHO, if you go down the storage modifier model, you have to let go of the idea
> of annotating local parameters, and stick to fields and arrays (e.g. "true"
> containers).

> This means that some of the "sharp" info would be lost on the way, and we would
> always use nullable representation on the stack.

> It's a trade off, of course - the programming model has less types, we lose
> ability for type information to flow from generic clients to containers and we
> also lose some ability to fully flatten on the stack (in the sense that a null
> side-channel will always need to be there, e.g. in the form of another
> synthetic parameter).
I think you're right, it's not a core part of the model, more something on the side. 
The VM can always speculate that the side-channel will be non-null by default (using an uncommon trap) especially if the type is know to be a value type (from the Preload attribute) so the ability to full flatten on the stack is not lost, only the calling convention need to take care of the side-channel. 

Also null tracking is not something Java the language does but a language like Kotlin should be able to generate a slightly better code using the TypeRestriction attribute. 

> Maurizio
Rémi 

> On 27/07/2022 01:02, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> From: "daniel smith" [ mailto:daniel.smith at oracle.com |
>>> <daniel.smith at oracle.com> ]
>>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ]
>>> Cc: "valhalla-spec-experts" [ mailto:valhalla-spec-experts at openjdk.java.net |
>>> <valhalla-spec-experts at openjdk.java.net> ]
>>> Sent: Wednesday, July 27, 2022 12:20:01 AM
>>> Subject: Re: The storage hint model

>>>> On Jul 20, 2022, at 9:44 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>>>> forax at univ-mlv.fr ] > wrote:

>>>> And not having .ref and .val to be types greatly simplify the model, because
>>>> they is no interaction between the type checking and the storage hints, those
>>>> are two separated concerns.

>>> To emphasize this point: I think we're talking about years of development time
>>> that could be cut from this project if we could live with storage modifiers
>>> rather than needing to thread the flattening information through the type
>>> system. Not to mention the downstream simplification for all the developers
>>> that don't have to learn what a value type is.

>>> (Think about it: no Q types, no .val/.ref, no boxing, no universal generics, no
>>> new unchecked warnings, no secondary reflection mirrors, no new descriptors, no
>>> bridges. Just a storage modifier akin to 'volatile', support for that modifier
>>> in arrays, and value classes able to opt in to allow that modifier.)

>>> But there are details to sort out, and those details will determine whether this
>>> simplifying move is a fantasy or a viable alternative design.

>> No bridges but you still need the Preload attribute.

>> The main drawback is that the storage hints are not available when you have an
>> abstract method, so you have to fallback to the idea that any type (type
>> variables included) is nullable when calling a virtual method (apart if the
>> type has already been loaded). Maybe the cost can be simulated by patching
>> javac to never generates a Q-type (apart from anewarray and fields) and
>> generate a Preload attribute instead.

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