value type hygiene

[John Rose]

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 <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/20180515/3d2dd69c/attachment.html>