Please read: Re: hg: valhalla/valhalla: 8222792: [lworld] Javac should enforce the latest relationship rules between an inline type and its nullable projection

Srikanth srikanth.adayapalam at oracle.com
Mon Apr 22 10:43:54 UTC 2019


With this change set:

     - The compiler treats LX; as a super type of QX; In the class file 
the super type is still jlO
     - Since X <: X?, expressions of type X can be assigned to variables 
of type X? freely, with no cast being required in the source code. Any 
explicit cast in the source will be discarded. In any event there will 
not be a checkcast in the class file for this widening operation. 
(absence of cast is a behavior change)
      - Expressions of type X? cannot be assigned to variables of type X 
without an express source cast.
X? is not assignable/convertible but is castable to X. VM can expect a 
checkcast in the binary.
     - We may relax the express source cast requirement for the 
narrowing operation at a later time
     - This change also impacts overload resolution. If we have:

      m(Object o) { }
      m(V? v) { }

and a call

      V v = …
      m(v)

prior to this change, 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 treat them both as 
applicable, and V? is _more specific_ than Object, so we pick m(V?)

      - As of now javac allows overloads that differ only in 
nullability. For example a class can have two methods m(V? v) and m(V 
v): overload selection behaves as can be expected based on what the 
compiler is able to discern at the compile time about the static types 
of the arguments. [Brian, thanks
for conforming this is what (or not) we want.)
     - I have cleaned up various hotspot runtime/compliler tests to 
adjust the code for the new behavior.
One exception is 
compiler/valhalla/valuetypes/TestNullableValueTypes.java - this test 
does not compile due to violating covariant return type rules and it is 
best for the author of the test to make suitable changes.
      - This change should also automatically cover the requirements for 
https://bugs.openjdk.java.net/browse/JDK-8222402 (LW2 array support in 
javac) which requires javac to implement "[QFoo;" <: "[LFoo;” <: 
“[LObject;” <: “Object;" - I am in the process of verifying this.

Thanks!
Srikanth


On 22/04/19 11:10 AM, srikanth.adayapalam at oracle.com wrote:
> Changeset: 8f61beecbe5e
> Author:    sadayapalam
> Date:      2019-04-22 11:09 +0530
> URL:       http://hg.openjdk.java.net/valhalla/valhalla/rev/8f61beecbe5e
>
> 8222792: [lworld] Javac should enforce the latest relationship rules between an inline type and its nullable projection
>
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConvention.java
> ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java
> ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableValueTypes.java
> ! test/hotspot/jtreg/runtime/valhalla/valuetypes/CheckcastTest.java
> ! test/hotspot/jtreg/runtime/valhalla/valuetypes/TestFieldNullability.java
> ! test/hotspot/jtreg/runtime/valhalla/valuetypes/TestValue1.java
> ! test/hotspot/jtreg/runtime/valhalla/valuetypes/TestValue2.java
> ! test/hotspot/jtreg/runtime/valhalla/valuetypes/TestValue3.java
> ! test/hotspot/jtreg/runtime/valhalla/valuetypes/TestValue4.java
> ! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTypeArray.java
> ! test/jdk/valhalla/valuetypes/NonFlattenValue.java
> ! test/langtools/tools/javac/valhalla/lworld-values/BoxValCastTest.java
> - test/langtools/tools/javac/valhalla/lworld-values/BoxValCastTest2.java
> ! test/langtools/tools/javac/valhalla/lworld-values/ValueConstructorRef.java
>




More information about the valhalla-dev mailing list