<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">I think we need to separate goals
(optimization) from mechanism (syntax). <br>
<br>
The optimizations you want to support seem to be exposing more
flattening possibilities when an interface is sealed to a union of
values, and especially one such class. Which is a fine goal. <br>
<br>
But if an interface is sealed to a union of values, the compiler
already knows that, and can issue a preload request anyway. <br>
<br>
If it turns out that later a `value` modifier has benefit _to the
user_, we can consider adding it later. But right now, this seems
like extrapolating syntax from no implementation examples. <br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 1/22/2024 1:34 PM, <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:1165691929.109121220.1705948443030.JavaMail.zimbra@univ-eiffel.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>"Dan Heidinga" <a class="moz-txt-link-rfc2396E" href="mailto:dan.heidinga@oracle.com"><dan.heidinga@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>, "daniel
smith" <a class="moz-txt-link-rfc2396E" href="mailto:daniel.smith@oracle.com"><daniel.smith@oracle.com></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>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;}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>
</blockquote>
<br>
</body>
</html>