<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Remi,<br>
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).</p>
<p>This means that some of the "sharp" info would be lost on the
way, and we would always use nullable representation on the stack.</p>
<p>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).</p>
<p>Maurizio<br>
</p>
<div class="moz-cite-prefix">On 27/07/2022 01:02, <a class="moz-txt-link-abbreviated" href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1319017271.15730754.1658880154315.JavaMail.zimbra@u-pem.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<div><br>
</div>
<div><br>
</div>
<hr id="zwchr" data-marker="__DIVIDER__">
<div data-marker="__HEADERS__">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"daniel smith" <a class="moz-txt-link-rfc2396E" href="mailto:daniel.smith@oracle.com"><daniel.smith@oracle.com></a><br>
<b>To: </b>"Remi Forax" <a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a><br>
<b>Cc: </b>"valhalla-spec-experts"
<a class="moz-txt-link-rfc2396E" href="mailto:valhalla-spec-experts@openjdk.java.net"><valhalla-spec-experts@openjdk.java.net></a><br>
<b>Sent: </b>Wednesday, July 27, 2022 12:20:01 AM<br>
<b>Subject: </b>Re: The storage hint model<br>
</blockquote>
</div>
<div data-marker="__QUOTED_TEXT__">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div>
<blockquote class="">
<div class="">On Jul 20, 2022, at 9:44 AM, Remi Forax
<<a href="mailto:forax@univ-mlv.fr" class="moz-txt-link-freetext" target="_blank" moz-do-not-send="true">forax@univ-mlv.fr</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="caret-color: rgb(0, 0, 0);
font-family: Helvetica; font-size: 12px; font-style:
normal; font-variant-caps: normal; font-weight: 400;
letter-spacing: normal; text-align: start;
text-indent: 0px; text-transform: none; white-space:
normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration:
none; float: none; display: inline !important;" class="">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.</span></div>
</blockquote>
</div>
<br class="">
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">(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.)</div>
<div class=""><br class="">
</div>
<div class="">But there are details to sort out, and those
details will determine whether this simplifying move is a
fantasy or a viable alternative design.</div>
</blockquote>
<div><br>
</div>
<div>No bridges but you still need the Preload attribute.</div>
<div><br data-mce-bogus="1">
</div>
<div>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.</div>
<div><br data-mce-bogus="1">
</div>
Rémi</div>
<div data-marker="__QUOTED_TEXT__"><br data-mce-bogus="1">
</div>
</div>
</blockquote>
</body>
</html>