Simplifying 'value' and 'identity'

[Dan Heidinga]

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.

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.


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.

--Dan


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