JEP 401 revisions: Null-Restricted Value Object Storage

[Dan Heidinga]

Some comments based on first reading:

> 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.
Should that say "implementation may optimize ..." as there are other
considerations, such as size, which effect flattening?

> 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.
Should this also mention array slots in addition to fields?

> Similarly, some value classes are like long and double, able to interpret
values implicitly created by non-atomic reads and writes.
This reads awkwardly.  Maybe adapt as "double, and are able to...."?
Otherwise the fragment following the second comma reads as incomplete.

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?

> A concrete class that implements LooselyConsistentValue (directly or
indirectly) must be a value class and must declare an implicit constructor.
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.

> 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.
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?

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.

--Dan

On Mon, Aug 14, 2023 at 7:26 PM Dan Smith <daniel.smith at oracle.com> wrote:

> 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.
>
> https://openjdk.org/jeps/401
>
> 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.
>
> (Don't forget that the core Value Objects concepts related to identity
> have been lifted out into their own JEP, https://openjdk.org/jeps/8277163,
> which is a prerequisite to JEP 401.)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230823/62293c73/attachment.htm>