<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">Yes, the eventual plan is that all
references can be null-restricted. We've been struggling with a
specific problem, though, which is that for a reference type like
`String!` or `Runnable!`, the VM is going to initialize such
variables with .. null. This is obviously a safety problem,
because we've put a value in a variable that is not provably
within the value set of the variable's type. It was for this
reason that earlier discussion focused on nullity control for
(implicitly constructible) values first, and other types later.<br>
<br>
Since then, we've figured out that we can solve this problem with
better flow analysis. Just like the DA analysis done by the
compiler, the VM can do a similar analysis during verification
time of fields that the compiler marks as "must be written before
they are read" (where any this-escape might lead to reading those
fields.) This goes under the name of "strict fields", and we
should be writing more about this soon. <br>
<br>
Once we have this tool in our kit, the limitations on what types
can be null-restricted -- and the safety with which we can enforce
this -- will be greatly broadened.<br>
</font><br>
<div class="moz-cite-prefix">On 6/9/2024 5:04 AM, Chen Liang wrote:<br>
</div>
<blockquote type="cite" cite="mid:SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hello valhalla community,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
In our current iteration of valhalla, we only support null
restriction on value fields, as for references, null is a valid
default value. Meanwhile, interfaces are not restricted to be
value or identity, yet some value classes will only be
represented via interfaces, most notably Map.entry().</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
In addition, consider this scenario in the ClassFile API: we
have ClassBuilder.withMethod(xxx, Consumer<MethodBuilder>)
and withMethodBody(xxx, Consumer<CodeBuilder>). A
straightforward implementation of withMethodBody would be
withMethod(xxx, new WithCode(cbConsumer)), where WithCode is
(value) record WithCode(Consumer<CodeBuilder> build)
implements Consumer<MethodBuilder>...</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
In this WithCode record, we can see that we are interested in
declaring "build" null-restricted; if build is a value lambda
that simply captures context variables, then WithCode can be
inlined to the same captures should "build" be NR, without
concerns about representing a null build value in the inlined
form.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Another example is in Algebraic types:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
sealed interface Operation permits O1, O2, ...</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Record O1(Interface1 xxx)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Record O2(Interface2 xxx)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
For value-based Interface1 and Interface2 values, we might seek
to NR the fields so the record representations can be simpler.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thus, I recommend considering support for NR on interface fields
in addition to on explicit value type fields. Though this might
lead down to the rabbit hole of "heap pollution of null on
reference pointers", I still believe its benefit outweighs its
cost, especially in cases where these values can be restricted
on the stack in escape analysis, as in most functional APIs
(function only invoked conditionally, function objects not
stored when method exits).</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Chen Liang</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
</blockquote>
<br>
</body>
</html>