Simplifying 'value' and 'identity'

[forax at univ-mlv.fr]

> From: "Dan Heidinga" <dan.heidinga at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "daniel smith" <daniel.smith at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Monday, January 22, 2024 4:48:56 PM
> Subject: Re: Simplifying 'value' and 'identity'
Hello, 

> Snip


> > Interfaces: all interfaces can be implemented by value classes and identity
> > classes. Full stop. If you have a particular need to limit the kinds of
> > implementing classes, you can use a sealed interface and provide the
> > implementation yourself, or you can make it an informal part of the contract.
> > But, like access control, synchronization, and other fine-grained,
> > implementation-oriented features, identity is not something interfaces can
> > explicitly control.

> > This approach has a two-state categorization scheme for classes expressed with
> > one keyword ('value' and identity). This corresponds to one JVM flag
> > (ACC_IDENTITY, for {reasons}). Interfaces have only one state.

> > What do we lose?
> > - You can't force an abstract class/interface to be implemented by *only* value
> > classes
> > - You can't force an interface to be implemented by *only* identity classes
> > - You can't declare an abstract class or interface whose type will refuse to
> > support the 'synchronized' keyword

> > I don't think any of these are enough to justify the extra costs of 3 states or
> > an 'identity' keyword. (For awhile, I was considering keeping around the
> > 'identity' keyword, just for the purpose of interfaces. But, eh, nobody is
> > going to use it.)

> Removing the 'identity' keyword is a good things, but i'm not so sure about not
> allowing users to declare a value interface, because i think that sealing the
> interface does not convey the right semantics.

> The problem is that in the future, a VM may want to flatten a sealed interface
> (with all its subtypes being value type), currently this is possible on stack
> but not on heap because '!' can not be used on anything but a value class.

> I’m not clear on how this would work at the VM level. To flatten on heap we need
> a single known layout that we can embed in the containing object / array. If we
> added value interfaces back into the language, we’d still be unable to know the
> field layout to embed in the containing object.

If the interface is preloaded, the VM has enough information to compute the tagged union. 
But storing on heap is IMO harder than reserving registers on stack + discriminator (the real class | null). 

> An interface that is sealed to a single value class may be a good candidate for
> layout heroics (and in some distance future, maybe an interface that is sealed
> to a small set of layouts could be flattened), but in both cases, the key
> determinate is that the interface is sealed to a set of value classes. Whether
> the interface is marked as value or not is irrelevant.

Currently, the VM will no try to flatten something which is not explicitly marked by a user as 'value'. 
I think it should be the same for sealed interfaces, the user should ask by tagging it as 'value' for the VM to consider it as a value interface. 
It will make the performance more predictable from the user POV. 

> I think we should allow an interface to be prefixed by "value" so
> - the compiler adds the interface in the Preload attribute
> - '!' is allowed on that interface (in that case all subtypes must be either a
> value interface or a value class with an implicit constructor)

> Guidance on when to add a class to the preload attribute is something that still
> needs to be worked out. A good first approximation is anywhere we had put a “Q”
> descriptor is a good candidate but there may be others (like the sealed
> interface case) that are interesting.

Being in the Preload attribute or not is something a user should be able to predict IMO and not something magic that the compiler may or may not do. 

> --Dan

regards, 
Rémi 

> regards,
> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20240122/ecd3af64/attachment.htm>