Value types design decisions

[-]

Hi John,
Glad to see you bring up constructive classes again, a proposal I
wholeheartedly love!
For those who don't know, John published two essay in his code review FTP
(also home to other outstanding essays):
https://cr.openjdk.org/~jrose/jvm/eager-super-init.html - Safe
construction, making final fields trusted, behaving like current @Stable or
static/hidden/record finals (works well with leyden's (computed) constants)
https://cr.openjdk.org/~jrose/jls/constructive-classes.html - Constructive
classes in Java programming language, fixing long-standing discrepancy
between normal final fields and inner class enclosing instance field (which
is written before super constructor call in bytecode)

And it seems you have already considered the possibility of inlining such
"rejecting initial value" fields in this slide (
https://cr.openjdk.org/~jrose/values/field-initializations.pdf) even though
I am not aware of its exact context. Would you mind sharing more
behind-the-scenes details?

Question: what do STM and HTM stand for? Unfortunately I am not that
familiar with hardware, and "doubly-periodic arrays" is also enigmatic to
me (I can't find anything from online searches). I hope you can give me
some references on these.

Also a few general remarks:
1. The Valhalla research and development has benefitted mainline JDK again.
Even though the "constructive classes" was initially an innovation to
prevent creating new bytecode sequences that breaks compatibility with the
existing new-dup-<init>, it now allows regular Java classes to have more
safety with their final fields and removed the long-standing weirdness of
having inner classes initialize their outer instance before super call; the
same happened back in JDK 11 when NestHost and NestMember were added, which
I recall was designed for creating subclasses for generic specialization,
but it removed all $accessor$0s generated by javac to access inner class
private members, boosting performance and reducing class file sizes.
2. Currently our value class is quite restrictive (no field in abstract
values, only null-restricted fields for zero-default value classes, etc)
but they are futureproof, as these capabilities can be expanded (algebraic
types with sealed, initialization-guard for final fields that reject
default values) without hurting backward compatibility. Love this way of
enhancement.

Chen


On Sun, Jan 21, 2024 at 5:13 AM Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "John Rose" <john.r.rose at oracle.com>
> > To: "-" <liangchenblue at gmail.com>
> > Cc: "Brian Goetz" <brian.goetz at oracle.com>, "David Alayachew" <
> davidalayachew at gmail.com>, "Smith Wilson"
> > <wilsons2401 at outlook.com>, "valhalla-dev" <valhalla-dev at openjdk.org>
> > Sent: Sunday, January 21, 2024 7:10:08 AM
> > Subject: Re: Value types design decisions
>
> > On 20 Jan 2024, at 21:20, - wrote:
> >
> >> Hi Brian, from your description of LocalDate![] comes a contingent
> question:
> >> Can (non-implicitly constructable) classes now have null-restricted
> >> (inlined) fields of types that are not implicitly constructable, given
> >> these fields will be initialized by the constructors to valid values? I
> >> assume any assignment of invalid values (notably, null) will simply
> result
> >> in exceptions such as NPE.
> >>
> >> If yes, how will such fields be represented in heap as:
> >> 1. identity object's final fields?
> >> 2. identity object's mutable fields?
> >> 3. non-implicitly constructable value object's final fields?
> >>
> >> Given these fields can have their proper states visible no later than
> their
> >> owner objects are visible.
> >>
> >> I think this is a new aspect of inlining that hasn't yet been discussed,
> >> but is probably worth discussing.
> >>
> >
> > That is well spotted.  As Brian said, “Stay tuned”.  Here is a teaser:
> >
> >
> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-December/002400.html
> >
> > You are right to imply that the implementation options are likely to
> differ for
> > immutable and mutable fields (and sub-fields of values).
> >
> > As a result of certain conversations last summer at JMVLS, our design for
> > Valhalla got simpler, because value and identity objects use more
> similar code
> > shapes for their construction.  That gave us a better logical framework
> for
> > thinking about problems and requirements of guaranteed field
> initialization,
> > the results of which will come out shortly.
> >
> > The basic insight is, if you can prove a field is initialized, you can
> tolerate
> > an abstraction-breaking initial value.  The fun problem is building out
> the
> > framework for making the necessary proofs, at the right levels in the
> stack.
> >
> > For mutable fields there is an additional problem, of course, of
> ensuring that
> > races (on a field of type V! or V) cannot expose values that the author
> of V
> > has deemed private to V.  (Allowing V to opt out of atomicity makes the
> VM’s
> > job easier.)  Once the initialization problem is solved, it is easier to
> attack
> > the “safe mutation” problem, with or without an atomicity requirement.
> All of
> > this stuff will happen “under the hood”.
> >
> > As Brian says, once the semantics are nailed down, then the
> optimizations can
> > start to show up.  Once the rules are set properly, the games can
> begin.  (I’m
> > talking about the VM implementation games, the kind of games I like
> best.)
> >
> > I expect to see a long line of VM optimizations arise in the future after
> > Valhalla, to flatten more and more value types, as optimizations get more
> > clever and hardware gets more capable.  My concern for this year is to
> get the
> > semantic rules into the right shape (for both language and VM).  That
> way the
> > best optimizations are possible in the future.
> >
> > Examples of possible future stuff:  Research on STM and HTM might be
> “mined” for
> > potential candidates to optimize flat, mutable data.  There are clever
> “cache
> > friendly” and “lock free” algorithms that might be applicable.  I have a
> > handful of pet ideas…  One is doubly-periodic arrays, where each array
> “card”
> > has N payloads and N null bits (or N big fields and N little fields; N
> might be
> > 7) but they are allocated column-style (within the card) instead of
> row-style
> > (which is what we do to day in the Valhalla prototype).  The card size
> is tuned
> > to the cache line size, of course.  The indexing arithmetic is
> surprisingly
> > clean, once you work it out.
>
>
> Another big area we have left on the side is the flattening of sealed
> (implicit or explicit) hierarchy of value types.
>
> >
> > — John
>
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240121/78ade37c/attachment.htm>