Slight inconsistency between state of valhalla and the value objects draft JEP

[Stig Rohde Døssing]

Thanks Rémi, that sounds great. Being able to flatten in fields (even if
only sometimes) is very nice. I was just concerned to read that viewing a
value object as an instance of a supertype would disable flattening for
parameters/return values, but if this can be avoided when the supertype is
sealed, that will work well enough for Option I think.

Den fre. 24. dec. 2021 kl. 00.28 skrev Remi Forax <forax at univ-mlv.fr>:

> ----- Original Message -----
> > From: "Stig Rohde Døssing" <stigdoessing at gmail.com>
> > To: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> > Sent: Thursday, December 23, 2021 11:13:03 PM
> > Subject: Slight inconsistency between state of valhalla and the value
> objects draft JEP
>
> > Hi,
> >
> > The updated state of valhalla at
> >
> https://openjdk.java.net/projects/valhalla/design-notes/state-of-valhalla/03-vm-model#flattening-and-representation
> > says that final fields containing value objects can regularly be
> flattened,
> > even when using the L descriptor. It also says that value objects might
> not
> > be flattenable if referenced through a non-sealed interface, which I
> > understand to mean that if it is referenced through a sealed interface,
> we
> > might not have to pay the polymorphism tax, and might still be able to
> > flatten?
> >
> > The draft JEP at https://openjdk.java.net/jeps/8277163 is more
> > conservative, and says that value objects in fields and value objects
> > viewed as an instance of a supertype will be heap allocated.
> >
> > Is the JEP just being a bit too conservative? It sounds great if
> flattening
> > is still possible as long as the fields are final or the superinterface
> is
> > sealed. I think this would make a big difference for Scala's Option type,
> > which is a sealed interface.
>
> To be able to flatten on heap, you need
> - the type to be loaded eagerly (a Q-type or a L-type in the Preload table)
>   - I see no issue to store a sealed interface in the Preload table
> - if it's a primitive type, it should not be too big
> - if it's a value type, it should be <= 64 bits knowing that you need a
> bit for nullability
>   (in practice a byte)
> - if it's a sealed interface, you need several bits to store the index of
> the permitted subtypes
>   (in practice a byte but you may reuse the same byte as above (255 or 128
> permitted subtypes seems a lot))
>
> So for Option, if the VM is using compressed oops (so no ZGC !), it should
> be okay.
>
> Now, does this heroic bits packing stuff will be implemented one day,
> maybe, the VM already does bits packing in the object header after all,
> but don't expect this to be implemented when Valhalla will be first
> released.
>
> Rémi
>