> From: "Maurizio Cimadamore" <[email protected]> > To: "Remi Forax" <[email protected]>, "daniel smith" <[email protected]> > Cc: "valhalla-spec-experts" <[email protected]> > 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:[email protected] | [email protected] ] wrote: >>> From: "daniel smith" [ mailto:[email protected] | >>> <[email protected]> ] >>> To: "Remi Forax" [ mailto:[email protected] | <[email protected]> ] >>> Cc: "valhalla-spec-experts" [ mailto:[email protected] >>> | >>> <[email protected]> ] >>> 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:[email protected] | >>>> [email protected] ] > 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
