Most recent JEP 401 description

[Chen Liang]

For your information, John Rose has recently written a few essays on layout
of flattened values in the VM:
https://cr.openjdk.org/~jrose/values/flattened-values.html
Also another recent article discussing loose consistency (old "primitive
classes"): https://cr.openjdk.org/~jrose/values/loose-consistency.html

On Wed, May 22, 2024 at 9:37 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> There are no restrictions in the specification.  However, the object
> layout algorithm is already quite complicated, so it is possible there will
> be implementation limitations, at least at first.
>
> On 5/19/2024 12:18 AM, John Bossons wrote:
>
> Thanks for the confirmation. Good news!
>
> As to 'no restrictions' re size (horizontal - number of fields), fine. But
> what about depth (vertical - fields that are value objects that in turn
> contain fields that are value objects etc. all the way down)? No constraint
> on depth of nesting?
>
>
>
>
>
> On Sat, May 18, 2024 at 8:21 PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> Amazingly, yes, value-capable abstract classes can have fields.  We
>> thought for many years this would never be possible; the Great
>> Initialization Alignment (eliminating `vnew` and `withfield` in favor of
>> the `new` and `putfield` approach) made this possible.
>>
>> The language imposes no restrictions on the number of fields of value
>> types.  The VM reserves the right to flatten, or not, based on its whims.
>> One likely whim is that "large" values are usually not worth flattening.
>> But this is invisible to the user; the semantics are the same whether or
>> not the object is flattened.
>>
>> On 5/18/2024 1:24 PM, John Bossons wrote:
>>
>> Thanks for making this so very clear.
>>
>> Two questions/issues:
>> (1) It would be helpful to include more on the properties of abstract
>> value classes (AVCs) -- perhaps a labelled subsection? A specific question
>> not dealt with explicitly in the current version: Can an AVC have an
>> instance field, now that a value class utilizes the Flexible Constructor
>> Bodies JEP? (The alternative is  repetition of that field definition and
>> accessor in every subtype, which is potentially error-prone).
>> (2) It would also be helpful to include some commentary on limitations.
>> Specifically, although it is clear that the purpose is more efficiently
>> defined SMALL value objects, (a) How big is 'small'? And (b) will the
>> compiler accept value types of any size, no matter how deep?
>>
>> John
>>
>>
>> Phone:  (416) 450-3584 (cell)
>>
>>
>>
>
> --
> Phone:  (416) 450-3584 (cell)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240522/0915fb31/attachment.htm>