value type hygiene

[Victor Nazarov]

Hi,

I've been following a discussion and noticed that most of it revolve around
arrays. I'd like to share an idea of mine that I find rather attractive
following a compatibility story.

What about arrays with null-bitmap. Arrays that are flattened array of
value types plus a bitmap of is-null-status glued togeather. Every write
operation to an array sets a nonnull-bit in a bitmap. For new clients that
are aware of value-typeness this is the whole story. Bitmap is
uninteresting to them. For legacy clients read operation can return null if
is-non-null bit is not set. And write operation can clear a nonnull-bit
when it writes null.

This bitmap is analogues to ValueType attribute: it'a side channel that
augments some operations.

--

Victor Nazarov

ср, 16 мая 2018 г., 1:53 John Rose <john.r.rose at oracle.com>:

> 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.
> >
> >
>
>