<div dir="ltr">Some comments based on first reading:<br><br>> The HotSpot implementation then optimizes these fields and arrays by storing value objects directly in flattened storage, without any object headers, indirections, or null flags.<br>Should that say "implementation may optimize ..." as there are other considerations, such as size, which effect flattening?<br><br>> As for primitive-typed fields, JVMs could be given permission to create this zero Point object implicitly by simply allocating a field of an appropriate type.<br>Should this also mention array slots in addition to fields?<br><br>> Similarly, some value classes are like long and double, able to interpret values implicitly created by non-atomic reads and writes.<br>This reads awkwardly.  Maybe adapt as "double, and are able to...."?  Otherwise the fragment following the second comma reads as incomplete.<br><br>In the "Null-restricted types" section, there's a "public Cursor(Point! position)" constructor shown but the JEP has so far only talked about type restrictions for fields and array slots.  We've talked about supporting type-restrictions in methods as being similar to erased generics (checked at the callsite) and also about not allowing it in method declarations yet.  Do we want to avoid showing the "!" in methods for this JEP?<br><br>> A concrete class that implements LooselyConsistentValue (directly or indirectly) must be a value class and must declare an implicit constructor.<br>Where is this check going to be specified? I think it needs to occur as part of verification (5.4.1) so the check is complete before static fields are prepared.  I think we need to assert the check both ways - having one of implements LooselyConsistentValue or ImplicitCreation[ACC_NON_ATOMIC] flag should fail verification.<br><br>> If the value of a field is implicitly set to a value class's initial instance, the named value class must be initialized before the field can be read.<br>What about before it can be written?  Does code that does a putstatic of Point.default to a Point! x field force Point to be initialized?  Or just a read from the "x" field?<br><br>I think the JEP needs to more explicitly handle what happens to method descriptors using the "!" syntax.  It shows of it but doesn't talk about how it is encoded, erased, or otherwise handled.<br><br>--Dan<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 14, 2023 at 7:26 PM Dan Smith <<a href="mailto:daniel.smith@oracle.com">daniel.smith@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've made some revisions to JEP 401 to align with our latest design ideas for expressing flattenability in the language and in class files.<br>
<br>
<a href="https://openjdk.org/jeps/401" rel="noreferrer" target="_blank">https://openjdk.org/jeps/401</a><br>
<br>
At one point I was considering introducing nullness features in a separate JEP, but the consensus seems to be that we're better off delivering a smaller version of nullness features first, only applicable to value classes. So I've revised the JEP title to be "Null-Restricted Value Object Storage" and eliminated the dependency on a separate nullness JEP.<br>
<br>
(Don't forget that the core Value Objects concepts related to identity have been lifted out into their own JEP, <a href="https://openjdk.org/jeps/8277163" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8277163</a>, which is a prerequisite to JEP 401.)<br>
<br>
</blockquote></div>