<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>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net><br><b>Sent: </b>Friday, April 21, 2023 12:27:12 AM<br><b>Subject: </b>Re: B3, default values, and implicit initialization<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;"><font size="4"><font face="monospace">As I mentioned yesterday, the
high order bit here is how we describe a class whose
(null-restricted) instances can tolerate (and possibly even
encourage) uninitialized use, just as the primitives do today.
Ignoring the surface syntax, what we really need is an evocative
term for such a class. This term has to be useful and evocative
to multiple participants:<br><br>
- The author of a class, who is making a decision about whether
the zero state represents a sensible default. <br>
- The client of a class, who may exploit the fact that
instances may be safely used uninitialized, or who may want to
reason about flattening. <br>
- The specification / descriptive documents, which will need a
way to talk about "classes that are friendly to uninitialized
use." <br><br>
This concept is made more difficult because this property will
only have observable effects for variables with null-restricted
types. </font></font></blockquote><div>.<br></div><div>The effects are not even observable for all variables, but only for instance fields, array elements, and parameters if the method is not inlined (and later not parametric).</div><div><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;"><font size="4"><font face="monospace"><br><br><br><br><br><br></font></font><br>
<div class="moz-cite-prefix">On 3/28/2023 3:13 PM, Brian Goetz
wrote:<br>
</div>
<blockquote cite="mid:61a456f3-88bc-553a-2310-50acf0fe9cf7@oracle.com">
<font size="4"><font face="monospace">The recent update of JEP 401
contained a number of refinements to the user model,
specifically, separating the primitive/reference distinction
into a number of smaller distinctions (e.g., nullable vs
non-nullable, optional vs required construction.) Overall
this has been a very positive step forward. <br><br>
We still have a need for the distinction between what we've
been calling B2 and B3; JEP 401 currently frames that in terms
of "construction is optional." This is a big step forward;
indeed, the key difference between them is whether the class
_needs_ the "variables start out as null, and all instances
are created by constructors" protection, or whether it admits
the lighter-weight initialization protocol of "there's a a
standard zero value, null-free variables are initialized to
that" that primitives enjoy today. (Note that B3 classes
don't require this lighter protocol, they merely enable it,
much as primitives all give you the option of boxing to get
the full conservative initialization protocol.)<br><br>
The idea of framing this as "construction is optional" is a
good one, but the expression of it proposed in JEP 401 feels
"not quite there". In this note I'll propose an alternative
presentation, but the main goal here is around terminology and
user model rather than syntax (so please keep the syntax
agitation to a reasonable level.)<br><br>
The key distinction between B2 and B3 is that B3 has a
_default value_ which the VM can summon at will. This enables
non-nullable heap variables to be flattened, because we can
initialize these the same way we initialize other fields and
array elements. Further, that default value is highly
constrained; it is a physical zero, the result of initializing
all fields to their default value. <br><br>
Flattening is of course a goal, but it is not something that
exists in the programming model -- its just an optimization.
What exists in the programming model is the default value, and
what this unlocks is the possibility for variables to be
_implicitly initializated_. Reference-typed variables today
are _explicitly initialized_; variables start out null and
have to be initialized with a constructed value. A class with
a default value has the option (opted in through
null-exclusion) for its variables to be implicitly
initialized, which, like primitives, means that they start out
with a valid default value, and can be further assigned to. <br><br>
Framed this way, the Valhalla performance story simplifies to:<br><br>
- Give up identity, get flattening on the stack;<br>
- Further give up explicit initialization, get flattening for
small objects on the heap;<br>
- Further give up atomicity, get flattening for larger
objects on the heap.<br><br>
Giving up explicit initialization entails both the class
opting out of explicit initialization, _and_ the variable
opting out of nullity. <br><br>
The key new terminology that comes out of this is implicit vs
explicit initialization. <br><br><br>
Syntactically, my preference is to indicate that the default
value can be summoned by giving a value class a _default
constructor_:<br><br></font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"> value class Complex { <br>
public final double re, im;<br><br>
public default Complex();<br>
}<br></font></font><br>
A default constructor has no arguments, no body, no throws
clause, and implicitly initializes all fields to their default
values. Unlike identity classes, value classes don't get
constructions implicitly; a value class must declare at least
one constructor, default or otherwise. This replaces the idea
of "optional constructor", which is a negative statement about
construction ("but you don't have to call me"), with a more
direct and positive statement that there is a _default
constructor_ with the required properties. <br><br>
Note that this is similar to the existing concept of "default
constructor", which you get for free in an identity class if
you don't specify any constructors. It is possible we can
unify these features (and also with constructors in "agnostic"
abstract classes), but first let's work out what it would mean
in value classes, and see if we like it.<br><br>
In this model, a B3 class is just a value class with a default
constructor -> a default constructor means that you have
the choice of implicit or explicit initialization ->
non-nullity at the use site opts into implicit initialization
-> B3! gets flattening (for small layouts.) <br><br><br></font></font> </blockquote>
<br><br></blockquote></div></div></body></html>