hg: valhalla/valhalla: 8221545: [lworld] Preliminary support for alternate denotation of values and boxes

John Rose john.r.rose at oracle.com
Wed Apr 17 19:55:50 UTC 2019


On Apr 16, 2019, at 7:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Let’s separate the language and VM aspects.
> 
> In the language, since V <: V?, no cast is needed when assigning a V to a V?.  And no CHECKCAST is needed for the corresponding code generation.

I agree with this, although it would be a slight help to require the extra
checkcast op.  Helpful in that it would give the VM extra local knowledge
about shifting between what might be different physical carrier formats.
Only "slight", in that the JVMS specifies that a common virtual carrier type,
a "reference", for every non-primitive, and *requires* that the interpreter
be ready to interconvert these references, at many points between any
underlying physical formats.  It's not clear to me that the checkcast plugs
an important hole that isn't also present elsewhere (though I might be
missing something).

> In the other direction, a CHECKCAST is definitely needed going from V? to V;

That's definitely true, because the JVM must mandate a NPE exception
is thrown if the value sets don't line up, and NPE must be thrown by an
instruction, and checkcast is the instruction for type checking (hence
value set narrowing).

> the question of whether the _language_ requires an explicit cast is still up in the air.

Yep.  Requiring the cast is OK for a start, kind of like prohibiting array
covariance was a start.  Since V? is the successor to V.box, and V.box
is to V as java.lang.Integer is to int (in some use cases we design V? for),
I think we all suspect that we'll end up making V? convert to V in similar
circumstances to those in which Integer converts to int.

> I think we should lean on explicit casting for now, but I suspect we’ll slide back to implicit narrowing (with possible NPE).  

I'll go out on a limb and mention (again) that I think a reasonable first
(and perhaps last) cut is to slot conversion from V? to V (we could call
it "null check conversion" in the JLS) right alongside the unboxing
conversion in the current JLS.  That is, do null check conversion in
the second pass of overload matching, at the same time as legacy
unboxing conversions.  (That's where boxing conversions happen,
but they don't have future analog, since V <: V?.)

This seems so self-evidently reasonable to me (at least as a first cut)
that perhaps we should, sooner rather than later, put a switch into the
prototype javac whichenables this behavior, with logging of the difference
in overloading choice between it and one which makes the casting required,
so we can quickly test its effect.

> This also makes a difference for overload selection.  If I have:
> 
>    m(Object o) { }
>    m(V? v) { }
> 
> and a call
> 
>    V v = …
>    m(v)
> 
> Under the old (V.box) interpretation, we’d prefer the m(Object) overload, since it is applicable without a boxing conversion, and m(V?) would not be.  But under the new (subtyping) interpretation, we should treat them both as applicable, and V? is _more specific_ than OIbject, so we pick m(V?).  

That's an argument to think about putting the V to V? conversion into
the second pass of the resolution logic, alongside boxing conversion.
Which seems a bridge too far, to compatibility-land.  My arguments
above (the opposite V? to V implicits, in the second pass) become
murkier due to this confounding factor, but I think they still stand.
The way to investigate is to run some corpus tests, and/or put a
switch with logging into javac, so we can look for and analyze
use cases.

It will always be possible to create sensitive overloading tests
which demonstrate the difference between putting implicits
in the first or second overloading stage (otherwise we wouldn't
have invented the staging structure in the first place).  But the
real question is what's useful, in the use cases we have today
and are likely to have tomorrow.

— John




More information about the valhalla-dev mailing list