Value types design decisions

[Remi Forax]

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