<html><body><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>"John Rose" <john.r.rose@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Brian Goetz" <brian.goetz@oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net><br><b>Sent: </b>Thursday, July 21, 2022 9:31:00 PM<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 style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 21 Jul 2022, at 6:54, <a href="mailto:forax@univ-mlv.fr" style="color: #3983C4;" target="_blank">forax@univ-mlv.fr</a> wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">…</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #BBBBBB; color: #BBBBBB;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #BBBBBB; color: #BBBBBB;"><p dir="auto">I've no idea about the performance of such kind of implementations, but >>> using</p>
</blockquote><p dir="auto">T.flat give better control on what is flattenable or not in the implementation.</p>
</blockquote><p dir="auto">If we choose, we can code this trick in the design of record as well.</p>
</blockquote><p dir="auto">You mean in the design of array ? I don't think it's wise given that the shape of the array change, but perhaps GCs can be modified to add a relocate and unflat operation to array.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">No, I mean in the design of ArrayList (or similar generics) in the way you sketch. If we choose we can create shape-shifting List/Map/etc. containers which ignore the <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">.val</code> channel in their type args (or there’s none at all, as you are proposing here), accept nulls, but have a better internal organization if no nulls are encountered dynamically.</p></div></div></blockquote><div><br data-mce-bogus="1"></div><div>I believe you need a T.val which forces to use the flat representation when the type argument of T is a value class but not a .val.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><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 style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">I say “if we choose” because there are reasons not to choose something that tricky and dynamic. Library designers have more options if <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">.val</code> is in the type channel.</p></div></div></blockquote><div><br></div><div>I believe that V8 has this kind of arrays for JavaScript.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><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 style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">…If some but not all of those
<br>
locations accept my chosen SC, my refactorings have greater friction.</p>
</blockquote><p dir="auto">If the variable is typed by a type variable, yes. But we have decided to have the exact same kind of friction
<br>
- with value class in practice because the VM is able to unmask the value class on stack but not on heap.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">Here by “friction” I think you mean hidden costs when heap placement of a value requires separate buffering of the payload also on heap. Alert users sometimes care about such subtleties. But (here’s the key point) users who just want the types to connect things up properly can ignore hidden costs and have a frictionless experience refactoring between heap and stack. That’s a win you don’t have when every user (alert or otherwise) is confronted with SC choices to align with type choices, during refactoring.</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">- with wildcards (you have to add those pesky ? extends/super).</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">I have a separate proposal to patch that. It’s irregular but (again) visible only to the very alert. A plain value class name <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>, when it appears as a type argument, should be treated as sugar for <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">? extends C.ref</code>. This is consistent, I claim, with the treatment of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> as sugar for <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code> in other contexts. It’s a little piece of the magic from Dan Smith’s thesis, applied specifically to the needs of type companions.</p>
</div></div></blockquote><div><br></div><div>Only when testing for subtyping relationship. Otherwise it means you can not add a C into a List of C.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>For me, this kind of trick are a symptom of the problem of using .val as a type channel, having two types for one value class means that most of the features that are using types in Java needs to be massaged (inference, overloading, subtyping, etc). Having a feature that requires re-interpretation of the spec everywhere should be a red flag. I'm not sure that my proposal of using storage hints is better but the cost of using .val as a type channel is scary.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>