<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>"Dan Heidinga" <dan.heidinga@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr>, "daniel smith" <daniel.smith@oracle.com><br><b>Cc: </b>"valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net><br><b>Sent: </b>Monday, January 22, 2024 4:48:56 PM<br><b>Subject: </b>Re: Simplifying 'value' and 'identity'</blockquote><div><br></div><div>Hello,<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;"><br></blockquote></div><div><style><!--
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style></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 class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Snip</span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt"><br>
> <br>
> Interfaces: all interfaces can be implemented by value classes and identity<br>
> classes. Full stop. If you have a particular need to limit the kinds of<br>
> implementing classes, you can use a sealed interface and provide the<br>
> implementation yourself, or you can make it an informal part of the contract.<br>
> But, like access control, synchronization, and other fine-grained,<br>
> implementation-oriented features, identity is not something interfaces can<br>
> explicitly control.<br>
> <br>
> This approach has a two-state categorization scheme for classes expressed with<br>
> one keyword ('value' and identity). This corresponds to one JVM flag<br>
> (ACC_IDENTITY, for {reasons}). Interfaces have only one state.<br>
> <br>
> What do we lose?<br>
> - You can't force an abstract class/interface to be implemented by *only* value<br>
> classes<br>
> - You can't force an interface to be implemented by *only* identity classes<br>
> - You can't declare an abstract class or interface whose type will refuse to<br>
> support the 'synchronized' keyword<br>
> <br>
> I don't think any of these are enough to justify the extra costs of 3 states or<br>
> an 'identity' keyword. (For awhile, I was considering keeping around the<br>
> 'identity' keyword, just for the purpose of interfaces. But, eh, nobody is<br>
> going to use it.)<br><br>
Removing the 'identity' keyword is a good things, but i'm not so sure about not allowing users to declare a value interface, because i think that sealing the interface does not convey the right semantics.<br><br>
The problem is that in the future, a VM may want to flatten a sealed interface (with all its subtypes being value type), currently this is possible on stack but not on heap because '!' can not be used on anything but a value class.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I’m not clear on how this would work at the VM level. To flatten on heap we need a single known layout that we can embed in the containing object / array. If we added value interfaces back into the language,
we’d still be unable to know the field layout to embed in the containing object.</span></p></div></div></div></div></blockquote><div><br></div><div>If the interface is preloaded, the VM has enough information to compute the tagged union.<br data-mce-bogus="1"></div><div>But storing on heap is IMO harder than reserving registers on stack + discriminator (the real class | null).</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 class="WordSection1"><div id="mail-editor-reference-message-container"><div><div>
<p class="MsoNormal"><span style="font-size:11.0pt">An interface that is sealed to a single value class may be a good candidate for layout heroics (and in some distance future, maybe an interface that is sealed to a small set of layouts could be flattened),
but in both cases, the key determinate is that the interface is sealed to a set of value classes. Whether the interface is marked as value or not is irrelevant.</span></p></div></div></div></div></blockquote><div><br></div><div>Currently, the VM will no try to flatten something which is not explicitly marked by a user as 'value'.<br data-mce-bogus="1"></div><div>I think it should be the same for sealed interfaces, the user should ask by tagging it as 'value' for the VM to consider it as a value interface.<br data-mce-bogus="1"></div><div>It will make the performance more predictable from the user POV.<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 class="WordSection1"><div id="mail-editor-reference-message-container"><div><div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt"><br><br>
I think we should allow an interface to be prefixed by "value" so<br>
- the compiler adds the interface in the Preload attribute<br>
- '!' is allowed on that interface (in that case all subtypes must be either a value interface or a value class with an implicit constructor)</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Guidance on when to add a class to the preload attribute is something that still needs to be worked out. A good first approximation is anywhere we had put a “Q” descriptor is a good candidate but there may
be others (like the sealed interface case) that are interesting.</span></p></div></div></div></div></blockquote><div><br></div><div>Being in the Preload attribute or not is something a user should be able to predict IMO and not something magic that the compiler may or may not do.<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 class="WordSection1"><div id="mail-editor-reference-message-container"><div><div>
<p class="MsoNormal"><span style="font-size:11.0pt">--Dan</span></p></div></div></div></div></blockquote><div><br></div><div>regards,<br data-mce-bogus="1"></div><div>Rémi<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 class="WordSection1"><div id="mail-editor-reference-message-container"><div><div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt"><br><br>
regards,<br>
Rémi</span></p>
</div>
</div>
</div>
</div><br></blockquote></div></div></body></html>