value type hygiene

[forax at univ-mlv.fr]

> 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é: Mardi 15 Mai 2018 01:53:31
> Objet: Re: value type hygiene

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

> In case it's not clear what I am proposing, I am not weighing in on language
> notations, but rather on VM structures in the context of the L-world experiment:

> - The L-world JVM should *not* be asked to invent two new runtime types for
> every VT.
> - Nullable references to value types in new code should be expressed using
> reference types.
> - In bytecodes, such nullable references can be Object or a new VT-specific
> interface or a mix of both.

I agree with your first 2 items but not the last one, a nullable reference should a L reference which is not listed in the attribute ValueTypes. 

So to be clear, what i'm proposing is to have a way at source level to say it's a value type at runtime but it behave like a reference type, 
so a class which is tagged with the value type bit and that the compiler doesn't list in the attribute ValueTypes. 

> In source code, I really don't care how nullability is expressed: annotation?
> keyword? punctuation? Java 5 generic? etc.

In my opinion, it has to be a declaration site thing not a use site thing but as you said, i do not mind if it's an annotation or a keyword. But it should not be an erased generics since it's a use site 'annotation'. 
That why i said i prefer an annotation at declaration site like @ValueBased. 

> In source code there is the *option* to use interface ValueRef<VT> to denote
> "nullable ref to VT", erased to "LValueRef;" in the JVM. I think that would be a
> clever use of erased static types, and a thrifty re-use of existing Java 5
> language
> features.

I do not think we need to invent something else that the attribute ValueTypes. 

> (Surely a bespoke syntax would be more concise; that's fine, but when it boils
> down to a JVM descriptor, please let it be non-nullable "LVT;" or else a
> reference
> type like "Ljava/lang/Object;" or "Ljava/lang/ValueMumble;", not a new kind of
> descriptor or an MVT-style mangled name. I am claiming we don't need that
> and don't want to pay for it. Please prove me wrong, if I am wrong, by
> experiment with a restricted L-world JVM running real code, and not by positing
> various unlikely compatibility puzzles.)

I agree with you. 

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

> (Now I'll respond to your suggestion of notation.)

> The annotation approach you suggest makes it nice and easy to sneak an
> annotation next to a use of a type. That's appealing. It's also sneaky since
> it slightly modifies the behavior of the problem (NPE vs. pass). The downside
> of the annotation is that, unless coupled with an annotation-sensitive
> translation
> strategy, the JVM has to mine through annotations to find out which descriptor
> components are nullable and which are not. The ValueTypes attribute is our
> best proposal yet for a way to pass the necessary information through to
> the JVM; surely you don't expect the JVM to turn around and look at
> type annotations in addition?

I was not clear in my previous mail, i was proposing a declaration site mechanism like the annotation, not to use that annotation at runtime. 

> I prefer ValueRef<VT> as a way to express nullability (instead of a type
> annotation)
> because it carries the same information, but all in the (static) type system.
> After erasure, the JVM can inspect the descriptor directly and immediately
> see whether the type is nullable or not. (ValueRef is *not* in the ValueTypes
> table. Simple!)

i think that the attribute ValueTypes is enough so we do not have to have another use site thingy. 

> You could also drive the translation strategy to perform surgery on descriptor
> elements annotated by @ValueBasedClass. Thus, an argument or return
> type of type VT with that annotation would be adjusted by the translation
> strategy to descriptor Object (erased from VT-or-null) or a suitable interface
> (such as ValueRef). That is an erasure, and so will disturb overloading rules
> and other things.

> Or we could push the annotation down into the descriptor syntax as a modifier.
> That's Q-world, with its own complementary problems we are trying to avoid
> by running the L-world experiment.

> One problem that shows up both at JVM and language level is that any
> special mechanisms we invent to grease the skids of migration will be
> with us forever, even after migration is a distant memory. I'd want a
> story for deprecating and removing API points that need the extra
> grease of @ValueBasedClass. Eventually @ValueBasedClass itself
> should be deprecated.

yes, we still use raw types but again if it's a class declaration hint for the compiler, it will be used for a handful class in the source code, it uses the attribute ValueTypes, for the VM side it's not another mechanism, it's the same mechanism but we let the end user to choose which kind of compatibility he wants. 

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

> +100. Trying to cleverly solve every last compatibility problem will
> freeze us into inaction.

> — John

Rémi