value type hygiene

[forax at univ-mlv.fr]

We can also restrict EVBC to be declared in the JDK (or java.base ?), because as far as i know, there is no other value based classes that currently exist, so the model exposed to the user is still object class vs value class. 

Also, I've come to realize that in a generified code an EVBC may be able to behave as a true value type because those codes doesn't already exist so there is less need to be backward compatible in this case. 

Rémi 

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 16 Mai 2018 00:53:02
> Objet: Re: value type hygiene

> More on your annotation proposal:

> One way to look at it is that you are proposing two new kinds of
> concrete classes to go with our old object class.

> - object class = what we have today: identity-rich, nullable, not flattened
> - value class = new, flattened*, not nullable, identity-free
> - enforced value-based class = new, nullable, not flattened, identity-free

> (* VM folks say "flattenable")

> Your annotation almost succeeds in being pure translation strategy,
> except that the JVM needs to be told to take care of the array type.
> So it's a little more than "just an annotation for javac".

> Dan seems to want to migrate many classes (most not enumerated)
> as EVBCs. And certainly LocalDate and friends would seem to slide
> easily into this mold.

> If we can implement EVBCs easily as a one-off from full value type,
> in the context of L-world, should we try it? People responsible for
> user model (hi Brian!) might say "yuck, we are admitting design
> failure by giving a consolation prize to the VBCs, instead of the
> real VTs promised". Maybe EVBCs are the best engineering
> compromise, or maybe we just cut EVBCs off the feature list
> and say "VT or VT not", at which point people who wrote VBCs
> will have sad decisions to make, and Dan will tell them not to
> migrate at all.

> From a VM POV, I think EVBCs are simple to implement on
> top of L-world, and so seem worth the experiment. One
> challenge will be to resist feature creep on EVBCs that
> would entrench them in a position as a true third kind
> of class. To avoid that, I like the idea of making them
> a one-off of one of the prime types: objects or values.
> And given that choice, having an annotation tweak them
> from a value type seems like a fine choice, at least
> from the VM POV.

> — John

> On May 14, 2018, at 4:13 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> I think i prefer a declaration site annotation like @ValueBasedClass to a use
>> site annotation ValueRef<V>.

>> For me a value based class, if you want to be as compatible as possible, is a
>> reference type (so 'L') that behave like a value type at runtime, so the JIT
>> can see it has a value type at runtime and can unbox it at will and buffer/box
>> it before calling a method at the horizon of the inlining blob.

>> So as a library designer, i can choose to either replace a class by a real value
>> type and it will fail if null is present or as a value based class if i value
>> (sorry !) the backward compatibility more than the performance.

>> Note that even if we solve the null issue when a reference type is changed to a
>> value type and i think it's not something we should focus on, there is still
>> the problem of the identity, so transforming a reference to a value type will
>> never be 100% compatible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20180516/33693bf6/attachment.html>