The storage hint model

[Maurizio Cimadamore]

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

Maurizio

On 27/07/2022 01:02, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"daniel smith" <daniel.smith at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"valhalla-spec-experts" <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 <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/16f9741d/attachment-0001.htm>