value type hygiene

Tue May 15 08:05:22 UTC 2018

> 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 08:56:49
> Objet: Re: value type hygiene

> On May 14, 2018, at 11:12 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>>> De: "John Rose" < [ mailto:john.r.rose at oracle.com | john.r.rose at oracle.com ] >
>>> À: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "Brian Goetz" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ]
>>> >, "valhalla-spec-experts" < [ mailto:valhalla-spec-experts at openjdk.java.net |
>>> 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>.

> D'oh. You said declaration site and you really meant it, at the declaration
> of the value class itself? I was responding as if you were proposing an
> use-site annotation, where a method is declared that uses a VT but
> wants to make that occurrence of the VT nullable. So, some of my
> reply was non-responsive; sorry.

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

> You must admit this use of supers to carry nullable values is possible,
> but you are saying (I think) that you don't agree that this is useful.

We have already decided that j.l.Object is the super that can carry null, so yes, we do not need another one. 

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

> What would be the benefit of such a value type? If it is nullable
> everywhere, conversely it is flattenable nowhere. That seems
> like it's giving up a fair chunk of valuable value-ness. The VT
> itself would resist identity checks (acmp => false). Would the
> arrays be flattenable or not? Seems to me that if a VT author
> uses such a big hammer to ask for nullability, the arrays also
> should allow null, hence be non-flattenable. I don't see much
> payoff from this user model.

In a sense, you're right, asking for nullability comes with a high cost, it's not flattenable (otherwise you can not store null), acmp => false (it's a value type at runtime) but you still have the fact that JITs that can spill a nullable value type in registers which is an important case. The idea is that even if a nullable value type escapes, the JIT doesn't have to keep it, it can spread it into its multiple components and gather it when it escapes. 

If you take a look to Optional or LocalDate, i'm not sure the need for flattening is that important, but being able to consider it has a value type inside an inlining blob (inside a function of the generated assembly) is important in term of performance when you do operation like map()/filter() or plus*()/minus*(). 

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

> Got it now; see above.

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

> Changing a VBC to a VT, and then putting @VBC on it, is like ten steps
> forward and nine steps back, if I'm correctly understanding the implications
> about flattening.

> So for def-site choices we have:

> 0. leave it alone, it's a VBC
> 1. make it a proper value type, get flattening on recompile, and deal with the
> null hygiene fallout
> 0.1 make it a value type but mark it @VBC, no sync or acmp, no flattening either

but it's nullable, the semantics is simple and mostly backward compatible (== does not work, use equals instead, do not synchronize on it) and no allocation cost where it can be important like in loops. 
in my opinion, yes, it's a trade off, but it's closer to 0.5 than 0.1. 

> The use-site choices for VTs are:

> 0. what choice? you didn't want that API point anyway
> 1. Object is the untyped workaround for all your nullable needs
> 1.2 clever ValueRef<VT> is your statically typed workaround for nullables

at the cost of some oddities like what ValueRef<?> or ValueRef.class means. 

> 2. Q-world: ad hoc variations everywhere between L-VT and Q-VT (cost += 1e6)
> 3. some sugar like VT.BOX or an annotation for one of the previous

and in all cases, each use-site choice means that people will have to annotate their code to make it works like it were working before with respect of null, so it's not really a practical option because Optional is so widespread in the code that all the codes that contains Optional will never be rewritten. 

> — John

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20180515/cdff33c0/attachment-0001.html>