Simplifying 'value' and 'identity'

[Brian Goetz]

I think we need to separate goals (optimization) from mechanism (syntax).

The optimizations you want to support seem to be exposing more 
flattening possibilities when an interface is sealed to a union of 
values, and especially one such class.  Which is a fine goal.

But if an interface is sealed to a union of values, the compiler already 
knows that, and can issue a preload request anyway.

If it turns out that later a `value` modifier has benefit _to the user_, 
we can consider adding it later.  But right now, this seems like 
extrapolating syntax from no implementation examples.



On 1/22/2024 1:34 PM, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *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/2ba0ab67/attachment-0001.htm>