From mcimadamore at openjdk.java.net  Fri May  1 00:12:47 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 1 May 2020 00:12:47 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: <CqOKiXD0aE-AaszWAr_QlJP8K6e2keqRj-VNGlophvI=.8ca65289-56d8-4b46-bcab-302f2271e25b@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
 <CqOKiXD0aE-AaszWAr_QlJP8K6e2keqRj-VNGlophvI=.8ca65289-56d8-4b46-bcab-302f2271e25b@github.com>
Message-ID: <uD4fdA3b5jC8Un6aETZG46X0WlEUvWZjNq2EXjLlJf0=.1e2e8fb7-b38a-4e61-9464-0bd3cb5d90e1@github.com>

On Thu, 30 Apr 2020 18:03:02 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> But I got an NPE where it was expected:

My bad - I realized that the test I put together was only compiling and not executing - sorry for the noise.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From mcimadamore at openjdk.java.net  Fri May  1 00:44:16 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 1 May 2020 00:44:16 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: <uD4fdA3b5jC8Un6aETZG46X0WlEUvWZjNq2EXjLlJf0=.1e2e8fb7-b38a-4e61-9464-0bd3cb5d90e1@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
 <CqOKiXD0aE-AaszWAr_QlJP8K6e2keqRj-VNGlophvI=.8ca65289-56d8-4b46-bcab-302f2271e25b@github.com>
 <uD4fdA3b5jC8Un6aETZG46X0WlEUvWZjNq2EXjLlJf0=.1e2e8fb7-b38a-4e61-9464-0bd3cb5d90e1@github.com>
Message-ID: <hkpUOaqLVm5dqokXcGtbzwRk-iw1D2JK4IVXgHPuWsM=.a16617ed-89af-4876-84e7-31066ebc9944@github.com>

On Fri, 1 May 2020 00:10:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've tried to reproduce the checkcast issue mentioned by Mauricio with this code:
>> public class Test2 {
>>     static inline class V {
>> 	int y = 52;
>>     }
>> 
>>     static void m(V.ref vr) {
>> 	V v = vr;
>>     }
>> 
>>     public static void main(String[] args) {
>> 	m(null);
>>     }
>> }
>> But I got an NPE where it was expected:
>> $ ./build/pull32/jdk/bin/java Test2
>> Exception in thread "main" java.lang.NullPointerException
>> 	at Test2.m(Test2.java:7)
>> 	at Test2.main(Test2.java:11)
>
>> But I got an NPE where it was expected:
> 
> My bad - I realized that the test I put together was only compiling and not executing - sorry for the noise.

> // Problem: 3, we infer a stream of X.ref's causing
>     // the method reference to not type check.
>     void unbound_lookup_with_projected_receiver() {
>         X [] a = new X[0];
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
> /*
> error: incompatible types: invalid method reference
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>                              ^
>     method data in class X cannot be applied to given types
>       required: no arguments
>       found:    X$ref
>       reason: actual and formal argument lists differ in length

For this one, I think something that an approach that could be discussed would be to consider the method reference
`V::m`, where `V` is an inline class, in the same way as we consider `List::add`. That is, we have `class name::member
name`.

In such cases we infer the right parameterization from the context; here it would be nice if we could infer the right
val/ref from the context too.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From mcimadamore at openjdk.java.net  Fri May  1 00:54:05 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 1 May 2020 00:54:05 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: <hkpUOaqLVm5dqokXcGtbzwRk-iw1D2JK4IVXgHPuWsM=.a16617ed-89af-4876-84e7-31066ebc9944@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
 <CqOKiXD0aE-AaszWAr_QlJP8K6e2keqRj-VNGlophvI=.8ca65289-56d8-4b46-bcab-302f2271e25b@github.com>
 <uD4fdA3b5jC8Un6aETZG46X0WlEUvWZjNq2EXjLlJf0=.1e2e8fb7-b38a-4e61-9464-0bd3cb5d90e1@github.com>
 <hkpUOaqLVm5dqokXcGtbzwRk-iw1D2JK4IVXgHPuWsM=.a16617ed-89af-4876-84e7-31066ebc9944@github.com>
Message-ID: <mHY8glcoLqZcl8iZPImE-FBvypiXNdwI11cwmTFtrHs=.307c774e-e0f4-44ed-a176-d9dc5f7369dc@github.com>

On Fri, 1 May 2020 00:41:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> But I got an NPE where it was expected:
>> 
>> My bad - I realized that the test I put together was only compiling and not executing - sorry for the noise.
>
>> // Problem: 3, we infer a stream of X.ref's causing
>>     // the method reference to not type check.
>>     void unbound_lookup_with_projected_receiver() {
>>         X [] a = new X[0];
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>> /*
>> error: incompatible types: invalid method reference
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>>                              ^
>>     method data in class X cannot be applied to given types
>>       required: no arguments
>>       found:    X$ref
>>       reason: actual and formal argument lists differ in length
> 
> For this one, I think something that an approach that could be discussed would be to consider the method reference
> `V::m`, where `V` is an inline class, in the same way as we consider `List::add`. That is, we have `class name::member
> name`.  In such cases we infer the right parameterization from the context; here it would be nice if we could infer the
> right val/ref from the context too.

Another odd test:

static inline class V  {
        int y = 52;

        class Bar { }
        static class Baz { }
    }

    public static void main(String[] args) {
        new V.ref().new Bar();
        new V().new Bar();
        V.Baz baz1;
        V.ref.Baz baz2;
    }

This gives:

error: cannot find symbol
        new V.ref().new Bar();
                        ^
  symbol:   class Bar
  location: class V$ref
error: cannot find symbol
        V.ref.Baz baz2;
             ^
  symbol:   class Baz
  location: class V$ref
2 errors
Now, I don't know what's the status of inner classes and values - but this seems to suggest that member types are not
copied from one scope to another (since the nested names are only resolved from the `val` projection.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 10:36:05 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 10:36:05 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: <tURDRP63NR4IUdpbL25pTnL-8AXUVG9EaYl5cPP2enY=.bea66b06-6485-4102-aac1-38acaa183b61@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <tURDRP63NR4IUdpbL25pTnL-8AXUVG9EaYl5cPP2enY=.bea66b06-6485-4102-aac1-38acaa183b61@github.com>
Message-ID: <IrUBguBdZmx0frlns_QrfanJhEt_P0bVW43RgnQSQwI=.00c7292f-9036-4e7e-babf-b1a13163f009@github.com>

On Thu, 30 Apr 2020 17:08:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Overall this looks very good. Note that changes to dot apply cleanly on latest lworld branch, so you might need some
> rebasing.

Thanks for the review, Maurizio!

(I will look into rebasing, At the time I raised the PR request it was even with openjdk/valhalla)

> I'm impressed at how much we could get done with relatively small set of changes in the core classes. As discussed
> offline, my mine gripe with the proposed implementation approach is that, I think, it distorts the user model view a
> little. In my mental model:

[...]

> * to help translation, a single inline class will be translated into a ref/val  classes pair - which means a single
>   inline class will give rise to _two_ runtime types
> 
> In other words, I think that appealing with symmetry with the generic use case, where a single declared class give rise
> to many types might be cleaner in the long run than having two declared classes (as in the proposed implementation).

I agree this suggestion if it is implementable, has promising upside potential to make the code relatively simpler.

I chose the present approach because:

* some of the state that (naturally) today belong in the class symbol abstraction needs to be distinct between the two
  projections. (name, flags, type ...)

* Various parts of javac code compare tsyms and assume the types are same if they are same (on the non-parameterized type
  path)

* there are places where we operates only on symbols and it is not clear we will unambiguously know the symbol ownership
  in those places.

These may all be solvable or worked around satisfactorily.

I agree that upside potential is promising enough to explore the presently unknown downside potential - JDK-8244227 is
raised to explore that, to prototype it so we can make an informed call.


> This choice surfaces up in a bunch of places where we have relationship which are seemingly defined on symbols (e.g.
> `Symbol::outermostClass`, and friends) in which we have to always ask first whether the class symbol we are dealing
> with is a _reference_ class symbol, and, if not, go back to that. This choice also backfires when it comes to keep the
> members of the two fictional symbols in sync - so there's a number of places where we have to update the scope of one
> class in the same way we update the scope of the other class.

I disagree with the vocabulary. It is not backfiring! It is additional work we knowingly sign up for :) But yes, it
would be good if we don't have to.

I must mention here that the LW2 implementation actually used two ClassSymbol shells that shared the members_field. I
had to opt for  a deeper copy to solve some problem I ran into which I am unable to recollect at my advanced geriatric
stage :)
 
> Note: all these things are not blockers - but to me they might be signs that some alternate implementation might be
> possible.
> The current approach will require adjustments in places where symbols are expected, but something like `V.ref` is
> found - for instance I put together this fictional example:
> ```
> package a;
> 
> import a.V.ref;
> 
> inline class V {
>    int x = 0;
> }
> ```
> 
> and I got this:
> 
> ```
> error: import requires canonical name for V$ref
> import a.V.ref;
>           ^
> ```
> 
> which seems a bit confusing (more generally I note that the compiler is often emitting V$ref and V$val which should be
> normalized to the syntax used by developers - e.g. dropping the dollar sign).
I have added this case to JDK-8244229 Thanks!


> I'm afraid that when the time will come and we will start looking at the annotation processing machinery, the choice of
> having two symbols (hence two `Elements`) for the `val` and `ref` projection might become untenable (since at that
> point I believe the annotation processor user would expect to get two different `TypeMirror`s for the projections which
> point to the same underlying declared `Element`). Since `Element` is 1-1 with `Symbol`, this might become a problem.

Hmm. As discussed offline, we may have to use some smoke and mirrors anyways to make them appear as one symbol when
dealing with binary classes from classpath.

> On a different topic, I noted something on name resolution:
> 
> ```
> inline class V {
>    int y = 52;
> 
>    static class ref {
>        int x;
>    }
> 
>    void m(V.ref vref) {
>        vref.x = 12;
>    }
> }
> ```
> 
> Which gives:
> 
> ```
> error: cannot find symbol
>        vref.x = 12;
>            ^
>   symbol:   variable x
>   location: variable vref of type V$ref
> ```
> 
> In other words, the compiler is always resolving `.ref` to a projection - which is fine for now, but there's a deeper
> question as to whether we're ok with this behavior and if we want to even allow defining a nested class called `ref` or
> `val` inside an inline class.

I have added this test case to JDK-8244229 Thanks!

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 10:50:13 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 10:50:13 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
Message-ID: <dS03n1AJ1UYLo0tu2TJHnmuWYaBR98nsyFb-Io222EY=.a66851dd-35c5-4efc-8436-70cb146b7df2@github.com>

On Thu, 30 Apr 2020 17:11:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hello Maurizio & Jim,
>> 
>>     May I request you to please review this patch for valhalla inline types support
>> under the new scheme ? TIA.
>> 
>> I.   What does this patch do?
>> II.  What can be skipped in the review?
>> III. Recommended order for review.
>> IV.  Known problems, limitations and deferred tasks.
>> V.   Report to language designers on open problems.
>> 
>> I. What does this patch do:
>> 
>>     - From every inline class declaration V, derive two classes V and V.ref
>>     - These two are subtypes at the VM level, but are related (only) by inline
>>       widening conversion and narrowing conversion at the language level.
>>     - The two types have the same fields and methods with the same shape and
>>       accessibility rules.
>>     - Add source level support for V.ref and V.val notation.
>>     - Get rid of the experimental support for generics over values. Until we
>>       figure out the full story with generics and inlines, carrying along this
>>       experimental support is becoming untenable/unsustainable.
>>     - Get rid of the experimental support added for noncovariant value arrays
>>     - Get rid of LW2's "Nullable Projections" including the V? syntax
>> 
>> II. These files can be skipped as they simply revert change and align
>>     with origin/master: (roll back V and V? nullable projections of LW2)
>> 
>>     JavacParser.java
>>     AttrContext.java
>>     JCTree.java
>>     Pretty.java
>>     Printer.java
>>     RichDiagnosticsFormatter.java
>>     TaskFactory.java
>>     TreeCopier.java
>>     TypePrinter.java
>> 
>> III. Recommended order for review:
>> 
>>     - Type.java, Symbol.java
>> 
>>             Look at the new internal APIs to query/compute various projections.
>>             Every class type, class symbol, method and field support an API
>>             to return the "other" projection i.e its doppleganger in the alternate
>>             universe.
>> 
>>             Most crucially ClassSymbol.referenceProjection()
>> 
>>     - Attr.java:
>> 
>>             Source support for .ref/.val
>> 
>>     - MemberEnter.java:
>>     - TypeEnter.java:
>>     - TransTypes.java:
>> 
>>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
>> 
>>     - TransValues.java:
>> 
>>             Fold all V.ref.member accesses to ((V) V.ref).member access.
>> 
>>     - Resolve.java:
>> 
>>             Changes to make sure method look up works OK in a world where values are islands.
>> 
>>     - Types.java:
>>   
>>             Implement inline widening/narrowing relationship.
>> 
>>     - ProjectionRelationsTest.java:
>> 
>>             Verify all relationships between V and V.ref and V[] and V.ref[]
>> 
>>     - ClassWriter.java:
>>             
>>             Dual class generation scheme with subtyping relationship at the binary/VM level.
>> 
>>     - ClassReader.java:
>> 
>>             Merge the dual classes back, sever the subtyping relationship and make
>>             them operate as a pair of classes that can convert to each other.
>> 
>>     - New tests:
>>     
>>             Most importantly ProjectionRelationsTest.java
>> 
>>     - Other files.
>> 
>>  
>> IV. There are many known issues that have been deliberately deferred to a later iteration:
>> 
>>     - With Brian's consent I am using a simpler translation strategy than what is
>>       outlined in the SoV documents. These are good enough for now, but when
>>       VBC migration is undertaken, will have to enhanced.
>>     - No support for ref-default and val-default classes yet.
>>     - No support for class hierarchy sealing.
>>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>>     - Handling of .ref and .val is quick and dirty; Need revisit.
>>     - The nest mate related attributes are not fully properly emitted as of now
>>     - Need to verify that attributes from V are not carried over inadvertantly to
>>       V$ref.class
>>     - Class hierarchy walking in a world where inline types are islands calls for
>>       a type switch. I have done this only in places uncovered by existing tests.
>>       We need to go through various utility methods (similar to what is done in
>>       Symbol.java and Resolve.java) to make sure these changes are consistently
>>       applied.
>>     - Diamond inference with value classes crashes now (implementation creates factory
>>       methods, projections are missing and need to be created)
>> 
>> 
>> V. Problems in the interplay of inlines types with generics and inference:
>> 
>>     Removing the experimental support for generics over values results in several
>> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
>> not compiling anymore.
>> 
>>     These expose some issues that feed into the language design. We need to evolve
>> a short term answer (so that the JDK components tests that are impacted don't get
>> blocked) and a long term one (the real solution)
>> 
>> Here is a snippet that captures these problems:
>> import java.util.Arrays;
>> 
>> interface I {}
>> 
>> public inline class X implements I {
>> 
>>     int x = 10;
>> 
>>     void problem_01() {
>>         X [] a1 = new X[0];
>>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>>       
>> /*
>> error: incompatible types: inference variable T has incompatible bounds
>>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>>                                          ^
>>     lower bounds: X,Object
>>     lower bounds: X$ref
>>   where T,U are type-variables:
>>     T extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>>     U extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>> 1 error
>> */
>>     }
>> 
>>     void foo(Class<? extends I> p) {}
>> 
>>     void problem_02() {
>>         foo(X.class);
>> /*
>> error: incompatible types: Class<X> cannot be converted to Class<? extends I>
>>         foo(X.class);
>> */
>>     }
>> 
>>     String data() {
>>         return null;
>>     }
>> 
>>     // Problem: 3, we infer a stream of X.ref's causing
>>     // the method reference to not type check.
>>     void unbound_lookup_with_projected_receiver() {
>>         X [] a = new X[0];
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>> /*
>> error: incompatible types: invalid method reference
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>>                              ^
>>     method data in class X cannot be applied to given types
>>       required: no arguments
>>       found:    X$ref
>>       reason: actual and formal argument lists differ in length
>> */
>>     }
>> 
>>     void problem_04() {
>> /*
>>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>>     Unsafe has been deprecated and marked for removal
>>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>>              ^
>> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
>> valueHeaderSize in class Unsafe cannot be applied to given types;
>>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>>                                          ^
>>   required: Class<V>
>>   found:    Class<Value2>
>>   reason: inference variable V has incompatible bounds
>>     equality constraints: Value2
>>     lower bounds: Object
>>   where V is a type-variable:
>>     V extends Object declared in method <V>valueHeaderSize(Class<V>)
>> */
>>     }
>> 
>>     void problem_05() {
>> /*
>> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class<CAP#1> and
>> Class<MyValue1$ref>
>>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>>                                                                          ^
>>   where CAP#1 is a fresh type-variable:
>>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
>> */
>>     }
>> 
>>     public static void main(String [] args) {
>>     }
>> }
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 441:
> 
>> 440:     public Symbol referenceProjection() {
>> 441:         return null;
>> 442:     }
> 
> How much would it help to have this return `this` ? It seems to me that there a lot of `if <value> ...
> referenceProjection()` going around.

It could result in cleaner code. I have this one JDK-8244232 to cover it.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1197:
> 
>> 1196:         public Type valueProjection() {
>> 1197:             if (!isReferenceProjection() || projection !=  null)
>> 1198:                 return projection;
> 
> Question here - since you have two symbols, getting a reference projection and value projection shouldn't be as simple
> as doing `tsym.XYZprojection().type` ? Why do we need to create new types here?

FTR, this is to preserve any parameterizations. The value projection of V.ref<String> is V.val<String> and not V.val<T>

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1760:
> 
>> 1759:                     if (isValue(t)) {
>> 1760:                         // (s) Value ? == (s) Value.ref
>> 1761:                         t = t.referenceProjection();
> 
> I didn't get these comments

It is saying the predicate is a value type is castable to a type s is the same as the predicate is its reference
projection castable to s.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 10:58:14 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 10:58:14 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
Message-ID: <4PAY3wu5qxoxF-D6fQjdbg8ddTU9Qvqhevr49ObIox8=.3b8e6652-e2e4-469c-923d-e9d5adba8788@github.com>

On Thu, 30 Apr 2020 17:19:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hello Maurizio & Jim,
>> 
>>     May I request you to please review this patch for valhalla inline types support
>> under the new scheme ? TIA.
>> 
>> I.   What does this patch do?
>> II.  What can be skipped in the review?
>> III. Recommended order for review.
>> IV.  Known problems, limitations and deferred tasks.
>> V.   Report to language designers on open problems.
>> 
>> I. What does this patch do:
>> 
>>     - From every inline class declaration V, derive two classes V and V.ref
>>     - These two are subtypes at the VM level, but are related (only) by inline
>>       widening conversion and narrowing conversion at the language level.
>>     - The two types have the same fields and methods with the same shape and
>>       accessibility rules.
>>     - Add source level support for V.ref and V.val notation.
>>     - Get rid of the experimental support for generics over values. Until we
>>       figure out the full story with generics and inlines, carrying along this
>>       experimental support is becoming untenable/unsustainable.
>>     - Get rid of the experimental support added for noncovariant value arrays
>>     - Get rid of LW2's "Nullable Projections" including the V? syntax
>> 
>> II. These files can be skipped as they simply revert change and align
>>     with origin/master: (roll back V and V? nullable projections of LW2)
>> 
>>     JavacParser.java
>>     AttrContext.java
>>     JCTree.java
>>     Pretty.java
>>     Printer.java
>>     RichDiagnosticsFormatter.java
>>     TaskFactory.java
>>     TreeCopier.java
>>     TypePrinter.java
>> 
>> III. Recommended order for review:
>> 
>>     - Type.java, Symbol.java
>> 
>>             Look at the new internal APIs to query/compute various projections.
>>             Every class type, class symbol, method and field support an API
>>             to return the "other" projection i.e its doppleganger in the alternate
>>             universe.
>> 
>>             Most crucially ClassSymbol.referenceProjection()
>> 
>>     - Attr.java:
>> 
>>             Source support for .ref/.val
>> 
>>     - MemberEnter.java:
>>     - TypeEnter.java:
>>     - TransTypes.java:
>> 
>>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
>> 
>>     - TransValues.java:
>> 
>>             Fold all V.ref.member accesses to ((V) V.ref).member access.
>> 
>>     - Resolve.java:
>> 
>>             Changes to make sure method look up works OK in a world where values are islands.
>> 
>>     - Types.java:
>>   
>>             Implement inline widening/narrowing relationship.
>> 
>>     - ProjectionRelationsTest.java:
>> 
>>             Verify all relationships between V and V.ref and V[] and V.ref[]
>> 
>>     - ClassWriter.java:
>>             
>>             Dual class generation scheme with subtyping relationship at the binary/VM level.
>> 
>>     - ClassReader.java:
>> 
>>             Merge the dual classes back, sever the subtyping relationship and make
>>             them operate as a pair of classes that can convert to each other.
>> 
>>     - New tests:
>>     
>>             Most importantly ProjectionRelationsTest.java
>> 
>>     - Other files.
>> 
>>  
>> IV. There are many known issues that have been deliberately deferred to a later iteration:
>> 
>>     - With Brian's consent I am using a simpler translation strategy than what is
>>       outlined in the SoV documents. These are good enough for now, but when
>>       VBC migration is undertaken, will have to enhanced.
>>     - No support for ref-default and val-default classes yet.
>>     - No support for class hierarchy sealing.
>>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>>     - Handling of .ref and .val is quick and dirty; Need revisit.
>>     - The nest mate related attributes are not fully properly emitted as of now
>>     - Need to verify that attributes from V are not carried over inadvertantly to
>>       V$ref.class
>>     - Class hierarchy walking in a world where inline types are islands calls for
>>       a type switch. I have done this only in places uncovered by existing tests.
>>       We need to go through various utility methods (similar to what is done in
>>       Symbol.java and Resolve.java) to make sure these changes are consistently
>>       applied.
>>     - Diamond inference with value classes crashes now (implementation creates factory
>>       methods, projections are missing and need to be created)
>> 
>> 
>> V. Problems in the interplay of inlines types with generics and inference:
>> 
>>     Removing the experimental support for generics over values results in several
>> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
>> not compiling anymore.
>> 
>>     These expose some issues that feed into the language design. We need to evolve
>> a short term answer (so that the JDK components tests that are impacted don't get
>> blocked) and a long term one (the real solution)
>> 
>> Here is a snippet that captures these problems:
>> import java.util.Arrays;
>> 
>> interface I {}
>> 
>> public inline class X implements I {
>> 
>>     int x = 10;
>> 
>>     void problem_01() {
>>         X [] a1 = new X[0];
>>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>>       
>> /*
>> error: incompatible types: inference variable T has incompatible bounds
>>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>>                                          ^
>>     lower bounds: X,Object
>>     lower bounds: X$ref
>>   where T,U are type-variables:
>>     T extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>>     U extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>> 1 error
>> */
>>     }
>> 
>>     void foo(Class<? extends I> p) {}
>> 
>>     void problem_02() {
>>         foo(X.class);
>> /*
>> error: incompatible types: Class<X> cannot be converted to Class<? extends I>
>>         foo(X.class);
>> */
>>     }
>> 
>>     String data() {
>>         return null;
>>     }
>> 
>>     // Problem: 3, we infer a stream of X.ref's causing
>>     // the method reference to not type check.
>>     void unbound_lookup_with_projected_receiver() {
>>         X [] a = new X[0];
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>> /*
>> error: incompatible types: invalid method reference
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>>                              ^
>>     method data in class X cannot be applied to given types
>>       required: no arguments
>>       found:    X$ref
>>       reason: actual and formal argument lists differ in length
>> */
>>     }
>> 
>>     void problem_04() {
>> /*
>>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>>     Unsafe has been deprecated and marked for removal
>>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>>              ^
>> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
>> valueHeaderSize in class Unsafe cannot be applied to given types;
>>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>>                                          ^
>>   required: Class<V>
>>   found:    Class<Value2>
>>   reason: inference variable V has incompatible bounds
>>     equality constraints: Value2
>>     lower bounds: Object
>>   where V is a type-variable:
>>     V extends Object declared in method <V>valueHeaderSize(Class<V>)
>> */
>>     }
>> 
>>     void problem_05() {
>> /*
>> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class<CAP#1> and
>> Class<MyValue1$ref>
>>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>>                                                                          ^
>>   where CAP#1 is a fresh type-variable:
>>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
>> */
>>     }
>> 
>>     public static void main(String [] args) {
>>     }
>> }
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2605:
> 
>> 2604:         readClassFileInternal(c);
>> 2605:         if (c.isValue()) {
>> 2606:             /* http://cr.openjdk.java.net/~briangoetz/valhalla/sov/04-translation.html
> 
> This approach leads to very compact code - but in javac-land it's a bit odd that we have to prune away members at this
> late stage. I wonder if some of the pruning could happen earlier (e.g. in TransValues?)

Actually, this code is trying to remove V$ref.class from its owner (the package symbol). The class finder would have
from the class path found V.class and V$ref.class and added them to the known classes. When V.class is completed and we
find that it is a value class, V.class has a "wrong" super type from javac pov. It needs to read V$ref.class and pick
up the "real" super type from there. In that process it needs to remove V$ref.class from the package owner as it not a
top level class at all (very similar to what happens for nested classes)

> test/langtools/tools/javac/valhalla/lworld-values/InferredValueParameterizationTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> The golden file seems to still be there  - even though this is now a positive test

Thanks, will remove it!

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From mcimadamore at openjdk.java.net  Fri May  1 11:24:04 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 1 May 2020 11:24:04 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: <4PAY3wu5qxoxF-D6fQjdbg8ddTU9Qvqhevr49ObIox8=.3b8e6652-e2e4-469c-923d-e9d5adba8788@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
 <4PAY3wu5qxoxF-D6fQjdbg8ddTU9Qvqhevr49ObIox8=.3b8e6652-e2e4-469c-923d-e9d5adba8788@github.com>
Message-ID: <L4XuD9halx9kKTE8OVFNs3k8oSahFlWd7gpjVb00pHk=.cad2e80b-98be-44ac-9081-d8eb6407af1b@github.com>

On Fri, 1 May 2020 10:53:14 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2605:
>> 
>>> 2604:         readClassFileInternal(c);
>>> 2605:         if (c.isValue()) {
>>> 2606:             /* http://cr.openjdk.java.net/~briangoetz/valhalla/sov/04-translation.html
>> 
>> This approach leads to very compact code - but in javac-land it's a bit odd that we have to prune away members at this
>> late stage. I wonder if some of the pruning could happen earlier (e.g. in TransValues?)
>
> Actually, this code is trying to remove V$ref.class from its owner (the package symbol). The class finder would have
> from the class path found V.class and V$ref.class and added them to the known classes. When V.class is completed and we
> find that it is a value class, V.class has a "wrong" super type from javac pov. It needs to read V$ref.class and pick
> up the "real" super type from there. In that process it needs to remove V$ref.class from the package owner as it not a
> top level class at all (very similar to what happens for nested classes)

Actually I meant to comment on ClassWriter and clicked on the wrong thing!

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 11:32:03 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 11:32:03 GMT
Subject: [lworld] [Rev 01] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
Message-ID: <YQTkF10KU10xPggbVmS3Gv0K_L8hJJ3sjKnsxPq72Qg=.13a984ba-b5a8-4e13-9714-1275e4af62ab@github.com>

On Thu, 30 Apr 2020 17:26:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Srikanth Adayapalam has updated the pull request with a new target base due to a merge or a rebase. The incremental
>> webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits
>> since the last revision:
>>  - Rebase + Remove stale golden file.
>>  - Fix trailing white spaces
>>  - 8237072: [lworld] Add support for denoting and deriving the reference projection
>>  - 8237072: [lworld] Add support for denoting and deriving the reference projection
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3704:
> 
>> 3703: compiler.err.generic.parameterization.with.value.type=\
>> 3704:     Inferred type {0} involves generic parameterization by an inline type
>> 3705:
> 
> Do you have examples when this can happen? Or is this a leftover (in which case I think Check.java could be cleaned up
> a bit)

We had a discussion about possibly turning it into a throw. I think let us leave it in for now till the generics story
is more evolved and we know where we are heading.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 11:31:38 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 11:31:38 GMT
Subject: [lworld] [Rev 01] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
Message-ID: <iYuP2WcyH3Lk3sJlvDTidSA5V9ACl1x7jzeJkkFYLPw=.c79f802f-ec05-492a-a780-ae317f2fee53@github.com>

> Hello Maurizio & Jim,
> 
>     May I request you to please review this patch for valhalla inline types support
> under the new scheme ? TIA.
> 
> I.   What does this patch do?
> II.  What can be skipped in the review?
> III. Recommended order for review.
> IV.  Known problems, limitations and deferred tasks.
> V.   Report to language designers on open problems.
> 
> I. What does this patch do:
> 
>     - From every inline class declaration V, derive two classes V and V.ref
>     - These two are subtypes at the VM level, but are related (only) by inline
>       widening conversion and narrowing conversion at the language level.
>     - The two types have the same fields and methods with the same shape and
>       accessibility rules.
>     - Add source level support for V.ref and V.val notation.
>     - Get rid of the experimental support for generics over values. Until we
>       figure out the full story with generics and inlines, carrying along this
>       experimental support is becoming untenable/unsustainable.
>     - Get rid of the experimental support added for noncovariant value arrays
>     - Get rid of LW2's "Nullable Projections" including the V? syntax
> 
> II. These files can be skipped as they simply revert change and align
>     with origin/master: (roll back V and V? nullable projections of LW2)
> 
>     JavacParser.java
>     AttrContext.java
>     JCTree.java
>     Pretty.java
>     Printer.java
>     RichDiagnosticsFormatter.java
>     TaskFactory.java
>     TreeCopier.java
>     TypePrinter.java
> 
> III. Recommended order for review:
> 
>     - Type.java, Symbol.java
> 
>             Look at the new internal APIs to query/compute various projections.
>             Every class type, class symbol, method and field support an API
>             to return the "other" projection i.e its doppleganger in the alternate
>             universe.
> 
>             Most crucially ClassSymbol.referenceProjection()
> 
>     - Attr.java:
> 
>             Source support for .ref/.val
> 
>     - MemberEnter.java:
>     - TypeEnter.java:
>     - TransTypes.java:
> 
>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
> 
>     - TransValues.java:
> 
>             Fold all V.ref.member accesses to ((V) V.ref).member access.
> 
>     - Resolve.java:
> 
>             Changes to make sure method look up works OK in a world where values are islands.
> 
>     - Types.java:
>   
>             Implement inline widening/narrowing relationship.
> 
>     - ProjectionRelationsTest.java:
> 
>             Verify all relationships between V and V.ref and V[] and V.ref[]
> 
>     - ClassWriter.java:
>             
>             Dual class generation scheme with subtyping relationship at the binary/VM level.
> 
>     - ClassReader.java:
> 
>             Merge the dual classes back, sever the subtyping relationship and make
>             them operate as a pair of classes that can convert to each other.
> 
>     - New tests:
>     
>             Most importantly ProjectionRelationsTest.java
> 
>     - Other files.
> 
>  
> IV. There are many known issues that have been deliberately deferred to a later iteration:
> 
>     - With Brian's consent I am using a simpler translation strategy than what is
>       outlined in the SoV documents. These are good enough for now, but when
>       VBC migration is undertaken, will have to enhanced.
>     - No support for ref-default and val-default classes yet.
>     - No support for class hierarchy sealing.
>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>     - Handling of .ref and .val is quick and dirty; Need revisit.
>     - The nest mate related attributes are not fully properly emitted as of now
>     - Need to verify that attributes from V are not carried over inadvertantly to
>       V$ref.class
>     - Class hierarchy walking in a world where inline types are islands calls for
>       a type switch. I have done this only in places uncovered by existing tests.
>       We need to go through various utility methods (similar to what is done in
>       Symbol.java and Resolve.java) to make sure these changes are consistently
>       applied.
>     - Diamond inference with value classes crashes now (implementation creates factory
>       methods, projections are missing and need to be created)
> 
> 
> V. Problems in the interplay of inlines types with generics and inference:
> 
>     Removing the experimental support for generics over values results in several
> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
> not compiling anymore.
> 
>     These expose some issues that feed into the language design. We need to evolve
> a short term answer (so that the JDK components tests that are impacted don't get
> blocked) and a long term one (the real solution)
> 
> Here is a snippet that captures these problems:
> import java.util.Arrays;
> 
> interface I {}
> 
> public inline class X implements I {
> 
>     int x = 10;
> 
>     void problem_01() {
>         X [] a1 = new X[0];
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>       
> /*
> error: incompatible types: inference variable T has incompatible bounds
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>                                          ^
>     lower bounds: X,Object
>     lower bounds: X$ref
>   where T,U are type-variables:
>     T extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>     U extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
> 1 error
> */
>     }
> 
>     void foo(Class<? extends I> p) {}
> 
>     void problem_02() {
>         foo(X.class);
> /*
> error: incompatible types: Class<X> cannot be converted to Class<? extends I>
>         foo(X.class);
> */
>     }
> 
>     String data() {
>         return null;
>     }
> 
>     // Problem: 3, we infer a stream of X.ref's causing
>     // the method reference to not type check.
>     void unbound_lookup_with_projected_receiver() {
>         X [] a = new X[0];
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
> /*
> error: incompatible types: invalid method reference
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>                              ^
>     method data in class X cannot be applied to given types
>       required: no arguments
>       found:    X$ref
>       reason: actual and formal argument lists differ in length
> */
>     }
> 
>     void problem_04() {
> /*
>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>     Unsafe has been deprecated and marked for removal
>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>              ^
> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
> valueHeaderSize in class Unsafe cannot be applied to given types;
>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>                                          ^
>   required: Class<V>
>   found:    Class<Value2>
>   reason: inference variable V has incompatible bounds
>     equality constraints: Value2
>     lower bounds: Object
>   where V is a type-variable:
>     V extends Object declared in method <V>valueHeaderSize(Class<V>)
> */
>     }
> 
>     void problem_05() {
> /*
> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class<CAP#1> and
> Class<MyValue1$ref>
>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>                                                                          ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
> */
>     }
> 
>     public static void main(String [] args) {
>     }
> }

Srikanth Adayapalam has updated the pull request with a new target base due to a merge or a rebase. The incremental
webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits
since the last revision:

 - Rebase + Remove stale golden file.
 - Fix trailing white spaces
 - 8237072: [lworld] Add support for denoting and deriving the reference projection
 - 8237072: [lworld] Add support for denoting and deriving the reference projection

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/32/files
  - new: https://git.openjdk.java.net/valhalla/pull/32/files/af7ce163..e3585a3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/32/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/32/webrev.00-01

  Stats: 79 lines in 4 files changed: 28 ins; 46 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/32/head:pull/32

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 11:34:47 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 11:34:47 GMT
Subject: [lworld] [Rev 01] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <YQTkF10KU10xPggbVmS3Gv0K_L8hJJ3sjKnsxPq72Qg=.13a984ba-b5a8-4e13-9714-1275e4af62ab@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
 <YQTkF10KU10xPggbVmS3Gv0K_L8hJJ3sjKnsxPq72Qg=.13a984ba-b5a8-4e13-9714-1275e4af62ab@github.com>
Message-ID: <2D5clwGfhOkUPKU_jaCt_W9OcwLYdmRxX4A7iJjq7dA=.d65da83f-c3e3-4c70-a3d5-3e9ce4f3cc18@github.com>

On Fri, 1 May 2020 11:29:59 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3704:
>> 
>>> 3703: compiler.err.generic.parameterization.with.value.type=\
>>> 3704:     Inferred type {0} involves generic parameterization by an inline type
>>> 3705:
>> 
>> Do you have examples when this can happen? Or is this a leftover (in which case I think Check.java could be cleaned up
>> a bit)
>
> We had a discussion about possibly turning it into a throw. I think let us leave it in for now till the generics story
> is more evolved and we know where we are heading.

No we don't know where this code could be exercised. All the inference scenarios are covered in the test case - which
is why it had to be changed into positive test - So this could technically go away - only reason is to hold onto it to
detect any surprises and to wait for generics story to crystalize.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 11:34:50 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 11:34:50 GMT
Subject: [lworld] [Rev 01] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
Message-ID: <0rzNHJnzIHqP9PU0mfurNHtJRbUaHSWwjudVMZLTckw=.e0777ce1-a8f4-42c4-a5bf-bc3711a514b2@github.com>

On Thu, 30 Apr 2020 17:32:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Srikanth Adayapalam has updated the pull request with a new target base due to a merge or a rebase. The incremental
>> webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits
>> since the last revision:
>>  - Rebase + Remove stale golden file.
>>  - Fix trailing white spaces
>>  - 8237072: [lworld] Add support for denoting and deriving the reference projection
>>  - 8237072: [lworld] Add support for denoting and deriving the reference projection
>
> test/langtools/tools/javac/valhalla/lworld-values/ProjectionRelationsTest.java line 1:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.
> 
> You might want to look at this test framework:
> 
> test/langtools/tools/lib/types/TypeHarness.java
> 
> An example of such a test is:
> 
> test/langtools/tools/javac/types/PrimitiveConversionTest.java

Thanks. This could come in handy for future. Appreciated.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 11:44:17 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 11:44:17 GMT
Subject: [lworld] [Rev 01] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <mHY8glcoLqZcl8iZPImE-FBvypiXNdwI11cwmTFtrHs=.307c774e-e0f4-44ed-a176-d9dc5f7369dc@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
 <CqOKiXD0aE-AaszWAr_QlJP8K6e2keqRj-VNGlophvI=.8ca65289-56d8-4b46-bcab-302f2271e25b@github.com>
 <uD4fdA3b5jC8Un6aETZG46X0WlEUvWZjNq2EXjLlJf0=.1e2e8fb7-b38a-4e61-9464-0bd3cb5d90e1@github.com>
 <hkpUOaqLVm5dqokXcGtbzwRk-iw1D2JK4IVXgHPuWsM=.a16617ed-89af-4876-84e7-31066ebc9944@github.com>
 <mHY8glcoLqZcl8iZPImE-FBvypiXNdwI11cwmTFtrHs=.307c774e-e0f4-44ed-a176-d9dc5f7369dc@github.com>
Message-ID: <SCIiPqGekONjtRqneKObkhvHUNRMIxHIdTQox46tAXs=.6ae320d9-1e20-402a-aaf0-9e7825afb721@github.com>

On Fri, 1 May 2020 00:51:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Another odd test:
> 
> ```
> static inline class V  {
>         int y = 52;
> 
>         class Bar { }
>         static class Baz { }
>     }
> 
>     public static void main(String[] args) {
>         new V.ref().new Bar();
>         new V().new Bar();
>         V.Baz baz1;
>         V.ref.Baz baz2;
>     }
> ```
> 
> This gives:
> 
> ```
> error: cannot find symbol
>         new V.ref().new Bar();
>                         ^
>   symbol:   class Bar
>   location: class V$ref
> error: cannot find symbol
>         V.ref.Baz baz2;
>              ^
>   symbol:   class Baz
>   location: class V$ref
> 2 errors
> ```

This is acknowledged as a known TODO in
com.sun.tools.javac.code.Symbol.ClassSymbol#referenceProjection

I have raised JDK-8244233 to cover it,

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From github.com+63007666+JimLaskey at openjdk.java.net  Fri May  1 11:49:52 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 1 May 2020 11:49:52 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
Message-ID: <ob0FgCbcWTZXm6WT6qOZBbDSko59s38z6TrUBLA_0z4=.5a00325c-56e5-47e1-89d4-65a8d30d62f4@github.com>

On Thu, 30 Apr 2020 04:27:10 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Hello Maurizio & Jim,
> 
>     May I request you to please review this patch for valhalla inline types support
> under the new scheme ? TIA.
> 
> I.   What does this patch do?
> II.  What can be skipped in the review?
> III. Recommended order for review.
> IV.  Known problems, limitations and deferred tasks.
> V.   Report to language designers on open problems.
> 
> I. What does this patch do:
> 
>     - From every inline class declaration V, derive two classes V and V.ref
>     - These two are subtypes at the VM level, but are related (only) by inline
>       widening conversion and narrowing conversion at the language level.
>     - The two types have the same fields and methods with the same shape and
>       accessibility rules.
>     - Add source level support for V.ref and V.val notation.
>     - Get rid of the experimental support for generics over values. Until we
>       figure out the full story with generics and inlines, carrying along this
>       experimental support is becoming untenable/unsustainable.
>     - Get rid of the experimental support added for noncovariant value arrays
>     - Get rid of LW2's "Nullable Projections" including the V? syntax
> 
> II. These files can be skipped as they simply revert change and align
>     with origin/master: (roll back V and V? nullable projections of LW2)
> 
>     JavacParser.java
>     AttrContext.java
>     JCTree.java
>     Pretty.java
>     Printer.java
>     RichDiagnosticsFormatter.java
>     TaskFactory.java
>     TreeCopier.java
>     TypePrinter.java
> 
> III. Recommended order for review:
> 
>     - Type.java, Symbol.java
> 
>             Look at the new internal APIs to query/compute various projections.
>             Every class type, class symbol, method and field support an API
>             to return the "other" projection i.e its doppleganger in the alternate
>             universe.
> 
>             Most crucially ClassSymbol.referenceProjection()
> 
>     - Attr.java:
> 
>             Source support for .ref/.val
> 
>     - MemberEnter.java:
>     - TypeEnter.java:
>     - TransTypes.java:
> 
>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
> 
>     - TransValues.java:
> 
>             Fold all V.ref.member accesses to ((V) V.ref).member access.
> 
>     - Resolve.java:
> 
>             Changes to make sure method look up works OK in a world where values are islands.
> 
>     - Types.java:
>   
>             Implement inline widening/narrowing relationship.
> 
>     - ProjectionRelationsTest.java:
> 
>             Verify all relationships between V and V.ref and V[] and V.ref[]
> 
>     - ClassWriter.java:
>             
>             Dual class generation scheme with subtyping relationship at the binary/VM level.
> 
>     - ClassReader.java:
> 
>             Merge the dual classes back, sever the subtyping relationship and make
>             them operate as a pair of classes that can convert to each other.
> 
>     - New tests:
>     
>             Most importantly ProjectionRelationsTest.java
> 
>     - Other files.
> 
>  
> IV. There are many known issues that have been deliberately deferred to a later iteration:
> 
>     - With Brian's consent I am using a simpler translation strategy than what is
>       outlined in the SoV documents. These are good enough for now, but when
>       VBC migration is undertaken, will have to enhanced.
>     - No support for ref-default and val-default classes yet.
>     - No support for class hierarchy sealing.
>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>     - Handling of .ref and .val is quick and dirty; Need revisit.
>     - The nest mate related attributes are not fully properly emitted as of now
>     - Need to verify that attributes from V are not carried over inadvertantly to
>       V$ref.class
>     - Class hierarchy walking in a world where inline types are islands calls for
>       a type switch. I have done this only in places uncovered by existing tests.
>       We need to go through various utility methods (similar to what is done in
>       Symbol.java and Resolve.java) to make sure these changes are consistently
>       applied.
>     - Diamond inference with value classes crashes now (implementation creates factory
>       methods, projections are missing and need to be created)
> 
> 
> V. Problems in the interplay of inlines types with generics and inference:
> 
>     Removing the experimental support for generics over values results in several
> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
> not compiling anymore.
> 
>     These expose some issues that feed into the language design. We need to evolve
> a short term answer (so that the JDK components tests that are impacted don't get
> blocked) and a long term one (the real solution)
> 
> Here is a snippet that captures these problems:
> import java.util.Arrays;
> 
> interface I {}
> 
> public inline class X implements I {
> 
>     int x = 10;
> 
>     void problem_01() {
>         X [] a1 = new X[0];
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>       
> /*
> error: incompatible types: inference variable T has incompatible bounds
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>                                          ^
>     lower bounds: X,Object
>     lower bounds: X$ref
>   where T,U are type-variables:
>     T extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>     U extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
> 1 error
> */
>     }
> 
>     void foo(Class<? extends I> p) {}
> 
>     void problem_02() {
>         foo(X.class);
> /*
> error: incompatible types: Class<X> cannot be converted to Class<? extends I>
>         foo(X.class);
> */
>     }
> 
>     String data() {
>         return null;
>     }
> 
>     // Problem: 3, we infer a stream of X.ref's causing
>     // the method reference to not type check.
>     void unbound_lookup_with_projected_receiver() {
>         X [] a = new X[0];
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
> /*
> error: incompatible types: invalid method reference
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>                              ^
>     method data in class X cannot be applied to given types
>       required: no arguments
>       found:    X$ref
>       reason: actual and formal argument lists differ in length
> */
>     }
> 
>     void problem_04() {
> /*
>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>     Unsafe has been deprecated and marked for removal
>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>              ^
> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
> valueHeaderSize in class Unsafe cannot be applied to given types;
>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>                                          ^
>   required: Class<V>
>   found:    Class<Value2>
>   reason: inference variable V has incompatible bounds
>     equality constraints: Value2
>     lower bounds: Object
>   where V is a type-variable:
>     V extends Object declared in method <V>valueHeaderSize(Class<V>)
> */
>     }
> 
>     void problem_05() {
> /*
> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class<CAP#1> and
> Class<MyValue1$ref>
>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>                                                                          ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
> */
>     }
> 
>     public static void main(String [] args) {
>     }
> }

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:546
    `outermost' - mix of quotes.
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1319
    `other' projection: If `this' - mix of quotes.
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1669
     // TODO: TYP?, CLINT? - are you tracking?
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1672
    I haven't seen enough Valhalla code to fully comment but 'r' and 'v' prefixes for 'ref' and 'val' might be too subtle.
    One lower case letter in an overloaded variable name is visually harder to discern. (Brevity is not the next readers
    friend.)
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1688
    I think this.flatname.append('$', this.name.table.names.ref); should be broken out into two? support methods.
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java: 1715
    The `other' projection: If `this' - mix of quotes.
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1805
   Just wonder if this common projection pattern (p ? p.x : null) could be broken out into support methods.
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1967
    The `other' projection: If `this' - mix of quotes (hate when cut and paste propagates the problem.)
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java:1027
    `other' projection: If `this' - mix of quotes
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:1048
   What if isValue(es) and !isValue(et)? Doesn't really follow the pattern of the old code.
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:1234
   Same question as above.
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:1627
   Tracking unspecified behaviour?
src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:2194
    Comment indent :-)
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java:4074
    Naively: What happens if rs.resolveIdent does raise an exception? sym undefined? exception propagated?
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java:4197
    Similarly to above.
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java:901
    Tracking tolerate Value.class for now?
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java:420
    Is there a plan to handle projection conversation without modifying the tree?

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Fri May  1 12:00:07 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 12:00:07 GMT
Subject: [lworld] [Rev 01] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <L4XuD9halx9kKTE8OVFNs3k8oSahFlWd7gpjVb00pHk=.cad2e80b-98be-44ac-9081-d8eb6407af1b@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
 <4PAY3wu5qxoxF-D6fQjdbg8ddTU9Qvqhevr49ObIox8=.3b8e6652-e2e4-469c-923d-e9d5adba8788@github.com>
 <L4XuD9halx9kKTE8OVFNs3k8oSahFlWd7gpjVb00pHk=.cad2e80b-98be-44ac-9081-d8eb6407af1b@github.com>
Message-ID: <R1H5fjloG28kT_60UUFJZJdFPhrtQ-4JZqeFkyVyDiA=.0cb39718-b699-4c4a-b11b-d5c3ee386b40@github.com>

On Fri, 1 May 2020 11:21:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Actually, this code is trying to remove V$ref.class from its owner (the package symbol). The class finder would have
>> from the class path found V.class and V$ref.class and added them to the known classes. When V.class is completed and we
>> find that it is a value class, V.class has a "wrong" super type from javac pov. It needs to read V$ref.class and pick
>> up the "real" super type from there. In that process it needs to remove V$ref.class from the package owner as it not a
>> top level class at all (very similar to what happens for nested classes)
>
> Actually I meant to comment on ClassWriter and clicked on the wrong thing!

Actually we don't prune anything, We simply don't write the methods. But carry along the symbols as we must because
there could be other files that are in the pipeline, (from same TU or otherwise)

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From github.com+63007666+JimLaskey at openjdk.java.net  Fri May  1 12:01:35 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 1 May 2020 12:01:35 GMT
Subject: [lworld] [Rev 01] RFR: 8243623: [lworld] Syntax and other
 mechanical changes in langtools tests for JDK-8237072
In-Reply-To: <GSvOlvR0RIsJeNz0p4KQxujRnyk_wg0wz_-7NQO_T04=.ac83dae1-ff89-463f-9ec0-9bf38b1de8a4@github.com>
References: <JjVqYR9rSeH9Xl5FkZyZlA6n8PbRVZbgCIym-0E7es8=.6be3c2ab-0b68-43d8-96e5-ba9dc2aecabe@github.com>
 <GSvOlvR0RIsJeNz0p4KQxujRnyk_wg0wz_-7NQO_T04=.ac83dae1-ff89-463f-9ec0-9bf38b1de8a4@github.com>
Message-ID: <mDvxeRkxZDAaaphfKuatjbQeYMiVXAzgZbQjzrzCHi4=.bd1c9b47-9d07-4b3e-a783-79c9e998ee53@github.com>

On Thu, 30 Apr 2020 07:40:34 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Jim,
>> 
>> May I request you to review these changes to langtools tests that anticipate and
>> align with JDK-8237072 ? These changes are mechanical in nature and I decided it
>> is best to separate them from the RFR for JDK-8237072 itself to help create sharper
>> focus on the important pieces there. (Non-mechanical meaningful test changes with
>> be included in that RFR itself)
>> 
>> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
>> refer to the reference projection of a value type V and its value projection.
>> The old syntax of V? is withdrawn. This change also has class file implications
>> where the descriptor/signature encodings will now start mentioning $ref in the
>> class pool entries. Also every inline type results in two class files now
>> one for each projection - with the reference projection class being the superclass
>> of the inline class.
>> 
>> I'll push them after your review and after JDK-8237072 itself is pushed.
>> Thanks in advance.
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated review comments

Marked as reviewed by JimLaskey at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/29


From github.com+63007666+JimLaskey at openjdk.java.net  Fri May  1 12:01:35 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 1 May 2020 12:01:35 GMT
Subject: [lworld] RFR: 8243623: [lworld] Syntax and other mechanical
 changes in langtools tests for JDK-8237072
In-Reply-To: <JjVqYR9rSeH9Xl5FkZyZlA6n8PbRVZbgCIym-0E7es8=.6be3c2ab-0b68-43d8-96e5-ba9dc2aecabe@github.com>
References: <JjVqYR9rSeH9Xl5FkZyZlA6n8PbRVZbgCIym-0E7es8=.6be3c2ab-0b68-43d8-96e5-ba9dc2aecabe@github.com>
Message-ID: <uznyXa2tomC4XSvOphiMw84tewyUmsh9zL_8v3gwbOE=.0ca2f80e-144a-4b2a-9f27-4e20ac6bfdef@github.com>

On Mon, 27 Apr 2020 04:42:21 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim,
> 
> May I request you to review these changes to langtools tests that anticipate and
> align with JDK-8237072 ? These changes are mechanical in nature and I decided it
> is best to separate them from the RFR for JDK-8237072 itself to help create sharper
> focus on the important pieces there. (Non-mechanical meaningful test changes with
> be included in that RFR itself)
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and after JDK-8237072 itself is pushed.
> Thanks in advance.

test/langtools/tools/javac/valhalla/lworld-values/ArrayCreationWithQuestion.java:27
    Indentation (tab vs space)
test/langtools/tools/javac/valhalla/lworld-values/CheckQuestionInMessages.java:13
    X.ref[] xa = new Object[10]; should it be X.ref[] xa = new Object.ref[10]; I'm sure it is correct (Object.ref doesn't
    exist) but there is an inconsistency with old code. Maybe add a comment.

Otherwise, good.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/29


From sadayapalam at openjdk.java.net  Fri May  1 15:10:35 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 1 May 2020 15:10:35 GMT
Subject: [lworld] [Rev 01] RFR: 8243625: [lworld] Co-evolve
 hotspot-compiler tests along with JDK-8237072
In-Reply-To: <2jYS17UipWQiTMk13r-p6vALummTyBPG_sVhjQZODUw=.9dd3d917-37c8-45fd-9542-0102609b285f@github.com>
References: <2jYS17UipWQiTMk13r-p6vALummTyBPG_sVhjQZODUw=.9dd3d917-37c8-45fd-9542-0102609b285f@github.com>
Message-ID: <0f1dyV2ROwVdAX70J3wtlG0ahE6YfkGP2ar5DSJ_oEs=.9b3b3cd1-030a-4096-8141-a87d11f78b41@github.com>

> Tobias,
> 
> May I request you to review these changes to hotspot-compiler tests that anticipate
> and align with JDK-8237072 ? These changes are mechanical in nature and I decided it
> is best to separate them from the RFR for JDK-8237072 itself to help create sharper
> focus on the important pieces there.
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and after JDK-8237072 itself is pushed.
> Thanks in advance.

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Include fixes from Tobias for compilation failures.

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/30/files
  - new: https://git.openjdk.java.net/valhalla/pull/30/files/035020ab..9d1f824a

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/30/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/30/webrev.00-01

  Stats: 22 lines in 3 files changed: 9 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/30/head:pull/30

PR: https://git.openjdk.java.net/valhalla/pull/30


From sarma.swaranga at gmail.com  Sun May  3 08:40:47 2020
From: sarma.swaranga at gmail.com (Swaranga Sarma)
Date: Sun, 3 May 2020 01:40:47 -0700
Subject: Memory layout benefits of inline classes
In-Reply-To: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
References: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
Message-ID: <CAGZD2TAdyyMPHh+BBPwAOVOhNPh58j67Xstf20=96mBfQ253hw@mail.gmail.com>

Did not see a response on this hence trying again. If this is too soon in
the project for such questions or if folks are too busy please let me know
- it is perfectly understandable.

-Swaranga

On Mon, Apr 27, 2020 at 12:44 AM Swaranga Sarma <sarma.swaranga at gmail.com>
wrote:

> The examples of the benefits of inline classes that I have seen in demos
> are things like high allocation of data classes in a tight loop. I was
> trying to understand how some of our existing code may benefit by using
> inline classes which is different from the examples seen. I have the
> following questions:
>
> 1. Optional: If we have a nullable members in a class, we would like to
> return an Optional<T> in the accessor for that member unless we have a
> reason to reduce the allocation. I recall somewhere that Optional might be
> an inline type in the future and this concern may no longer be valid. Is my
> understanding correct?
>
> 2. CompletableFuture: Similar to Optional, is this a candidate for
> potentially turning into an inline type?
>
> 3. Regular data classes: In a lot of our code bases, we have data classes
> that look like:
> class Identifier {
>   final @NonNull Name name;
>   final @NonNull Id id;
> }
>
> class Name {
>   final @NonNull String value;
> }
>
> class Id {
>   final @NonNull String value;
> }
>
> We create instances like these and pass these around to other methods.
> Those methods access the necessary values using the access methods like
> identifier.name().value() or identifier.id().value(). These classes are
> probably good candidates for migrating to records. But I was also
> interested to understand if we also made them inline classes what memory
> layout benefits would we get. Would the pointer de-referencing problem go
> away in such cases?
>
> To put it in another way, most of our data classes boil down to Strings,
> and assuming String will not become an inline type, would there be any
> memory-layout benefits of making such classes inline?
>
> Regards
> Swaranga
>


From sadayapalam at openjdk.java.net  Mon May  4 00:26:40 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 4 May 2020 00:26:40 GMT
Subject: [lworld] [Rev 01] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <SCIiPqGekONjtRqneKObkhvHUNRMIxHIdTQox46tAXs=.6ae320d9-1e20-402a-aaf0-9e7825afb721@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <W3QySWKMpsCSE5EmCgISh_RewH31TYav-rbZDDyOqIs=.c0ae8d9b-c6bf-4641-a458-0edfa066a739@github.com>
 <CqOKiXD0aE-AaszWAr_QlJP8K6e2keqRj-VNGlophvI=.8ca65289-56d8-4b46-bcab-302f2271e25b@github.com>
 <uD4fdA3b5jC8Un6aETZG46X0WlEUvWZjNq2EXjLlJf0=.1e2e8fb7-b38a-4e61-9464-0bd3cb5d90e1@github.com>
 <hkpUOaqLVm5dqokXcGtbzwRk-iw1D2JK4IVXgHPuWsM=.a16617ed-89af-4876-84e7-31066ebc9944@github.com>
 <mHY8glcoLqZcl8iZPImE-FBvypiXNdwI11cwmTFtrHs=.307c774e-e0f4-44ed-a176-d9dc5f7369dc@github.com>
 <SCIiPqGekONjtRqneKObkhvHUNRMIxHIdTQox46tAXs=.6ae320d9-1e20-402a-aaf0-9e7825afb721@github.com>
Message-ID: <EocrArmazsCpZp1ANrHYGXEb689HHilctpVEPmczbeQ=.774517be-8fbf-4fb5-9b05-574b57af20a8@github.com>

On Fri, 1 May 2020 11:41:30 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Another odd test:
>> 
>> static inline class V  {
>>         int y = 52;
>> 
>>         class Bar { }
>>         static class Baz { }
>>     }
>> 
>>     public static void main(String[] args) {
>>         new V.ref().new Bar();
>>         new V().new Bar();
>>         V.Baz baz1;
>>         V.ref.Baz baz2;
>>     }
>> 
>> This gives:
>> 
>> error: cannot find symbol
>>         new V.ref().new Bar();
>>                         ^
>>   symbol:   class Bar
>>   location: class V$ref
>> error: cannot find symbol
>>         V.ref.Baz baz2;
>>              ^
>>   symbol:   class Baz
>>   location: class V$ref
>> 2 errors
>> Now, I don't know what's the status of inner classes and values - but this seems to suggest that member types are not
>> copied from one scope to another (since the nested names are only resolved from the `val` projection.
>
>> Another odd test:
>> 
>> ```
>> static inline class V  {
>>         int y = 52;
>> 
>>         class Bar { }
>>         static class Baz { }
>>     }
>> 
>>     public static void main(String[] args) {
>>         new V.ref().new Bar();
>>         new V().new Bar();
>>         V.Baz baz1;
>>         V.ref.Baz baz2;
>>     }
>> ```
>> 
>> This gives:
>> 
>> ```
>> error: cannot find symbol
>>         new V.ref().new Bar();
>>                         ^
>>   symbol:   class Bar
>>   location: class V$ref
>> error: cannot find symbol
>>         V.ref.Baz baz2;
>>              ^
>>   symbol:   class Baz
>>   location: class V$ref
>> 2 errors
>> ```
> 
> This is acknowledged as a known TODO in
> com.sun.tools.javac.code.Symbol.ClassSymbol#referenceProjection
> 
> I have raised JDK-8244233 to cover it,

> ```
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:546
>     `outermost' - mix of quotes.
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1319
>     `other' projection: If `this' - mix of quotes.
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java: 1715
>     The `other' projection: If `this' - mix of quotes.
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1967
>     The `other' projection: If `this' - mix of quotes (hate when cut and paste propagates the problem.)
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java:1027
>     `other' projection: If `this' - mix of quotes

I have cleaned up these, but this is a common coding/commenting convention in Javac. See that in the same files
Symbol.java & Type.java, there are about 20 other unrelated places where quotes in this `style' exist :)

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1669
>      // TODO: TYP?, CLINT? - are you tracking?

Yes: JDK-8244233

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1672
>     I haven't seen enough Valhalla code to fully comment but 'r' and 'v' prefixes for 'ref' and 'val' might be too subtle.
>     One lower case letter in an overloaded variable name is visually harder to discern. (Brevity is not the next readers
>     friend.)

Agreed it is poor choice. Fixed by expanding to ref* and val*

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1688
>     I think this.flatname.append('$', this.name.table.names.ref); should be broken out into two? support methods.
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java:1805
>    Just wonder if this common projection pattern (p ? p.x : null) could be broken out into support methods.

I have left these as is for now, as it is not clear what exactly is being suggested. If the original code is not clear
enough, do outline what you have in mind. TIA

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:1048
>    What if isValue(es) and !isValue(et)? Doesn't really follow the pattern of the old code.
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:1234
>    Same question as above.

Basically, we are checking here if T[] <: S[]. This is true if T.ref <: S. Example of such a check being is Point [] <:
Object []

If the polarity is reversed and we are checking if Object[] <: Point [], we would come up with
    es = Point
    et =  Object

and return isSubtype(object, Point)

which will return false which is indeed the right answer for if Object[] <: Point []

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:1627
>    Tracking unspecified behaviour?

Two clarifications: (1) there is no "behavior" here. it is only a comment I have left in for our reference as we are
going to hit it the moment we are going to add support for inline type arguments. (2) And because we are going to hit
it most definitely as soon as we start working on generics support that there is no ticket for that per se.
 
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java:2194
>     Comment indent :-)

Fixed.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java:4074
>     Naively: What happens if rs.resolveIdent does raise an exception? sym undefined? exception propagated?
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java:4197
>     Similarly to above.

The top level exception handling really happens in com.sun.tools.javac.main.Main#compile(java.lang.String[],
com.sun.tools.javac.util.Context) in the various catch blocks between lines 330-356.


> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java:901
>     Tracking tolerate Value.class for now?

I have fixed the comment to just say: "tolerate Value.class" dropping the "for now" - The comment can be confusing. We
should *always* tolerate and not report error on Value.class - thanks for catching this. (the "for now" originally
meant "may be there are other such cases we will discover we may have need to support also" but we have't found
anything else that must be tolerated)

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java:420
>     Is there a plan to handle projection conversation without modifying the tree?
> ```

No, this may not be doable - it is the intrinsic/organic cost of saying inline types are islands (i.e they have no
supertypes of any kind in the lang model including jlO and any declared super types). The best that can be done is to
ensure (a) the swicheroo happens for the narrowest window needed (b) the tree is restored in a finally block

Many many thanks for the review Jim!

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Mon May  4 04:02:14 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 4 May 2020 04:02:14 GMT
Subject: [lworld] [Rev 02] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
Message-ID: <jlxEL4HC30e8wLgN3DLZ-wN27oUbH4gAZs0ZJXfOepk=.97b76456-5182-4ae6-bbf2-8f06ec1dee13@github.com>

> Hello Maurizio & Jim,
> 
>     May I request you to please review this patch for valhalla inline types support
> under the new scheme ? TIA.
> 
> I.   What does this patch do?
> II.  What can be skipped in the review?
> III. Recommended order for review.
> IV.  Known problems, limitations and deferred tasks.
> V.   Report to language designers on open problems.
> 
> I. What does this patch do:
> 
>     - From every inline class declaration V, derive two classes V and V.ref
>     - These two are subtypes at the VM level, but are related (only) by inline
>       widening conversion and narrowing conversion at the language level.
>     - The two types have the same fields and methods with the same shape and
>       accessibility rules.
>     - Add source level support for V.ref and V.val notation.
>     - Get rid of the experimental support for generics over values. Until we
>       figure out the full story with generics and inlines, carrying along this
>       experimental support is becoming untenable/unsustainable.
>     - Get rid of the experimental support added for noncovariant value arrays
>     - Get rid of LW2's "Nullable Projections" including the V? syntax
> 
> II. These files can be skipped as they simply revert change and align
>     with origin/master: (roll back V and V? nullable projections of LW2)
> 
>     JavacParser.java
>     AttrContext.java
>     JCTree.java
>     Pretty.java
>     Printer.java
>     RichDiagnosticsFormatter.java
>     TaskFactory.java
>     TreeCopier.java
>     TypePrinter.java
> 
> III. Recommended order for review:
> 
>     - Type.java, Symbol.java
> 
>             Look at the new internal APIs to query/compute various projections.
>             Every class type, class symbol, method and field support an API
>             to return the "other" projection i.e its doppleganger in the alternate
>             universe.
> 
>             Most crucially ClassSymbol.referenceProjection()
> 
>     - Attr.java:
> 
>             Source support for .ref/.val
> 
>     - MemberEnter.java:
>     - TypeEnter.java:
>     - TransTypes.java:
> 
>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
> 
>     - TransValues.java:
> 
>             Fold all V.ref.member accesses to ((V) V.ref).member access.
> 
>     - Resolve.java:
> 
>             Changes to make sure method look up works OK in a world where values are islands.
> 
>     - Types.java:
>   
>             Implement inline widening/narrowing relationship.
> 
>     - ProjectionRelationsTest.java:
> 
>             Verify all relationships between V and V.ref and V[] and V.ref[]
> 
>     - ClassWriter.java:
>             
>             Dual class generation scheme with subtyping relationship at the binary/VM level.
> 
>     - ClassReader.java:
> 
>             Merge the dual classes back, sever the subtyping relationship and make
>             them operate as a pair of classes that can convert to each other.
> 
>     - New tests:
>     
>             Most importantly ProjectionRelationsTest.java
> 
>     - Other files.
> 
>  
> IV. There are many known issues that have been deliberately deferred to a later iteration:
> 
>     - With Brian's consent I am using a simpler translation strategy than what is
>       outlined in the SoV documents. These are good enough for now, but when
>       VBC migration is undertaken, will have to enhanced.
>     - No support for ref-default and val-default classes yet.
>     - No support for class hierarchy sealing.
>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>     - Handling of .ref and .val is quick and dirty; Need revisit.
>     - The nest mate related attributes are not fully properly emitted as of now
>     - Need to verify that attributes from V are not carried over inadvertantly to
>       V$ref.class
>     - Class hierarchy walking in a world where inline types are islands calls for
>       a type switch. I have done this only in places uncovered by existing tests.
>       We need to go through various utility methods (similar to what is done in
>       Symbol.java and Resolve.java) to make sure these changes are consistently
>       applied.
>     - Diamond inference with value classes crashes now (implementation creates factory
>       methods, projections are missing and need to be created)
> 
> 
> V. Problems in the interplay of inlines types with generics and inference:
> 
>     Removing the experimental support for generics over values results in several
> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
> not compiling anymore.
> 
>     These expose some issues that feed into the language design. We need to evolve
> a short term answer (so that the JDK components tests that are impacted don't get
> blocked) and a long term one (the real solution)
> 
> Here is a snippet that captures these problems:
> import java.util.Arrays;
> 
> interface I {}
> 
> public inline class X implements I {
> 
>     int x = 10;
> 
>     void problem_01() {
>         X [] a1 = new X[0];
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>       
> /*
> error: incompatible types: inference variable T has incompatible bounds
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>                                          ^
>     lower bounds: X,Object
>     lower bounds: X$ref
>   where T,U are type-variables:
>     T extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>     U extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
> 1 error
> */
>     }
> 
>     void foo(Class<? extends I> p) {}
> 
>     void problem_02() {
>         foo(X.class);
> /*
> error: incompatible types: Class<X> cannot be converted to Class<? extends I>
>         foo(X.class);
> */
>     }
> 
>     String data() {
>         return null;
>     }
> 
>     // Problem: 3, we infer a stream of X.ref's causing
>     // the method reference to not type check.
>     void unbound_lookup_with_projected_receiver() {
>         X [] a = new X[0];
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
> /*
> error: incompatible types: invalid method reference
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>                              ^
>     method data in class X cannot be applied to given types
>       required: no arguments
>       found:    X$ref
>       reason: actual and formal argument lists differ in length
> */
>     }
> 
>     void problem_04() {
> /*
>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>     Unsafe has been deprecated and marked for removal
>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>              ^
> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
> valueHeaderSize in class Unsafe cannot be applied to given types;
>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>                                          ^
>   required: Class<V>
>   found:    Class<Value2>
>   reason: inference variable V has incompatible bounds
>     equality constraints: Value2
>     lower bounds: Object
>   where V is a type-variable:
>     V extends Object declared in method <V>valueHeaderSize(Class<V>)
> */
>     }
> 
>     void problem_05() {
> /*
> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class<CAP#1> and
> Class<MyValue1$ref>
>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>                                                                          ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
> */
>     }
> 
>     public static void main(String [] args) {
>     }
> }

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate review comments from Jim Laskey

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/32/files
  - new: https://git.openjdk.java.net/valhalla/pull/32/files/e3585a3b..44b80d88

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/32/webrev.02
 - incr: https://webrevs.openjdk.java.net/valhalla/32/webrev.01-02

  Stats: 20 lines in 4 files changed: 0 ins; 0 del; 20 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/32/head:pull/32

PR: https://git.openjdk.java.net/valhalla/pull/32


From github.com+63007666+JimLaskey at openjdk.java.net  Mon May  4 12:17:56 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 4 May 2020 12:17:56 GMT
Subject: [lworld] [Rev 02] RFR: 8237072: [lworld] Add support for denoting
 and deriving the reference projection
In-Reply-To: <jlxEL4HC30e8wLgN3DLZ-wN27oUbH4gAZs0ZJXfOepk=.97b76456-5182-4ae6-bbf2-8f06ec1dee13@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
 <jlxEL4HC30e8wLgN3DLZ-wN27oUbH4gAZs0ZJXfOepk=.97b76456-5182-4ae6-bbf2-8f06ec1dee13@github.com>
Message-ID: <OozGS7yWcvSIj3HiwSyCnFeQ4Iod7jh-9LLhNxPN7Mk=.4482a37e-56de-4c8b-8dba-11361b232a54@github.com>

On Mon, 4 May 2020 04:02:14 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Hello Maurizio & Jim,
>> 
>>     May I request you to please review this patch for valhalla inline types support
>> under the new scheme ? TIA.
>> 
>> I.   What does this patch do?
>> II.  What can be skipped in the review?
>> III. Recommended order for review.
>> IV.  Known problems, limitations and deferred tasks.
>> V.   Report to language designers on open problems.
>> 
>> I. What does this patch do:
>> 
>>     - From every inline class declaration V, derive two classes V and V.ref
>>     - These two are subtypes at the VM level, but are related (only) by inline
>>       widening conversion and narrowing conversion at the language level.
>>     - The two types have the same fields and methods with the same shape and
>>       accessibility rules.
>>     - Add source level support for V.ref and V.val notation.
>>     - Get rid of the experimental support for generics over values. Until we
>>       figure out the full story with generics and inlines, carrying along this
>>       experimental support is becoming untenable/unsustainable.
>>     - Get rid of the experimental support added for noncovariant value arrays
>>     - Get rid of LW2's "Nullable Projections" including the V? syntax
>> 
>> II. These files can be skipped as they simply revert change and align
>>     with origin/master: (roll back V and V? nullable projections of LW2)
>> 
>>     JavacParser.java
>>     AttrContext.java
>>     JCTree.java
>>     Pretty.java
>>     Printer.java
>>     RichDiagnosticsFormatter.java
>>     TaskFactory.java
>>     TreeCopier.java
>>     TypePrinter.java
>> 
>> III. Recommended order for review:
>> 
>>     - Type.java, Symbol.java
>> 
>>             Look at the new internal APIs to query/compute various projections.
>>             Every class type, class symbol, method and field support an API
>>             to return the "other" projection i.e its doppleganger in the alternate
>>             universe.
>> 
>>             Most crucially ClassSymbol.referenceProjection()
>> 
>>     - Attr.java:
>> 
>>             Source support for .ref/.val
>> 
>>     - MemberEnter.java:
>>     - TypeEnter.java:
>>     - TransTypes.java:
>> 
>>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
>> 
>>     - TransValues.java:
>> 
>>             Fold all V.ref.member accesses to ((V) V.ref).member access.
>> 
>>     - Resolve.java:
>> 
>>             Changes to make sure method look up works OK in a world where values are islands.
>> 
>>     - Types.java:
>>   
>>             Implement inline widening/narrowing relationship.
>> 
>>     - ProjectionRelationsTest.java:
>> 
>>             Verify all relationships between V and V.ref and V[] and V.ref[]
>> 
>>     - ClassWriter.java:
>>             
>>             Dual class generation scheme with subtyping relationship at the binary/VM level.
>> 
>>     - ClassReader.java:
>> 
>>             Merge the dual classes back, sever the subtyping relationship and make
>>             them operate as a pair of classes that can convert to each other.
>> 
>>     - New tests:
>>     
>>             Most importantly ProjectionRelationsTest.java
>> 
>>     - Other files.
>> 
>>  
>> IV. There are many known issues that have been deliberately deferred to a later iteration:
>> 
>>     - With Brian's consent I am using a simpler translation strategy than what is
>>       outlined in the SoV documents. These are good enough for now, but when
>>       VBC migration is undertaken, will have to enhanced.
>>     - No support for ref-default and val-default classes yet.
>>     - No support for class hierarchy sealing.
>>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>>     - Handling of .ref and .val is quick and dirty; Need revisit.
>>     - The nest mate related attributes are not fully properly emitted as of now
>>     - Need to verify that attributes from V are not carried over inadvertantly to
>>       V$ref.class
>>     - Class hierarchy walking in a world where inline types are islands calls for
>>       a type switch. I have done this only in places uncovered by existing tests.
>>       We need to go through various utility methods (similar to what is done in
>>       Symbol.java and Resolve.java) to make sure these changes are consistently
>>       applied.
>>     - Diamond inference with value classes crashes now (implementation creates factory
>>       methods, projections are missing and need to be created)
>> 
>> 
>> V. Problems in the interplay of inlines types with generics and inference:
>> 
>>     Removing the experimental support for generics over values results in several
>> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
>> not compiling anymore.
>> 
>>     These expose some issues that feed into the language design. We need to evolve
>> a short term answer (so that the JDK components tests that are impacted don't get
>> blocked) and a long term one (the real solution)
>> 
>> Here is a snippet that captures these problems:
>> import java.util.Arrays;
>> 
>> interface I {}
>> 
>> public inline class X implements I {
>> 
>>     int x = 10;
>> 
>>     void problem_01() {
>>         X [] a1 = new X[0];
>>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>>       
>> /*
>> error: incompatible types: inference variable T has incompatible bounds
>>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>>                                          ^
>>     lower bounds: X,Object
>>     lower bounds: X$ref
>>   where T,U are type-variables:
>>     T extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>>     U extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>> 1 error
>> */
>>     }
>> 
>>     void foo(Class<? extends I> p) {}
>> 
>>     void problem_02() {
>>         foo(X.class);
>> /*
>> error: incompatible types: Class<X> cannot be converted to Class<? extends I>
>>         foo(X.class);
>> */
>>     }
>> 
>>     String data() {
>>         return null;
>>     }
>> 
>>     // Problem: 3, we infer a stream of X.ref's causing
>>     // the method reference to not type check.
>>     void unbound_lookup_with_projected_receiver() {
>>         X [] a = new X[0];
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>> /*
>> error: incompatible types: invalid method reference
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>>                              ^
>>     method data in class X cannot be applied to given types
>>       required: no arguments
>>       found:    X$ref
>>       reason: actual and formal argument lists differ in length
>> */
>>     }
>> 
>>     void problem_04() {
>> /*
>>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>>     Unsafe has been deprecated and marked for removal
>>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>>              ^
>> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
>> valueHeaderSize in class Unsafe cannot be applied to given types;
>>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>>                                          ^
>>   required: Class<V>
>>   found:    Class<Value2>
>>   reason: inference variable V has incompatible bounds
>>     equality constraints: Value2
>>     lower bounds: Object
>>   where V is a type-variable:
>>     V extends Object declared in method <V>valueHeaderSize(Class<V>)
>> */
>>     }
>> 
>>     void problem_05() {
>> /*
>> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class<CAP#1> and
>> Class<MyValue1$ref>
>>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>>                                                                          ^
>>   where CAP#1 is a fresh type-variable:
>>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
>> */
>>     }
>> 
>>     public static void main(String [] args) {
>>     }
>> }
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Jim Laskey

Marked as reviewed by JimLaskey at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From thartmann at openjdk.java.net  Mon May  4 14:04:09 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 4 May 2020 14:04:09 GMT
Subject: [lworld] RFR: 8244339: [lworld] JIT support for inline types with
 abstract class supertypes
Message-ID: <OlvpvWNG7zuHvj_wgJlMFa-W8FgyK2r4F4amVkQrRVg=.31cc2057-be37-4e00-8891-d09e23f1fad3@github.com>

C1 and C2 do not correctly handle and optimize inline types with abstract class supertypes and corresponding array
covariance. I've fixed and refactored related code. Added lots of tests and IR verification of optimizations.

-------------

Commit messages:
 - 8244339: [lworld] JIT support for inline types with abstract class supertypes

Changes: https://git.openjdk.java.net/valhalla/pull/33/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/33/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244339
  Stats: 1011 lines in 17 files changed: 917 ins; 15 del; 79 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/33.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/33/head:pull/33

PR: https://git.openjdk.java.net/valhalla/pull/33


From rwestrel at redhat.com  Mon May  4 14:44:58 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 04 May 2020 16:44:58 +0200
Subject: [lworld] RFR: 8244339: [lworld] JIT support for inline types with
 abstract class supertypes
In-Reply-To: <OlvpvWNG7zuHvj_wgJlMFa-W8FgyK2r4F4amVkQrRVg=.31cc2057-be37-4e00-8891-d09e23f1fad3@github.com>
References: <OlvpvWNG7zuHvj_wgJlMFa-W8FgyK2r4F4amVkQrRVg=.31cc2057-be37-4e00-8891-d09e23f1fad3@github.com>
Message-ID: <87imhb7o9h.fsf@redhat.com>


> C1 and C2 do not correctly handle and optimize inline types with abstract class supertypes and corresponding array
> covariance. I've fixed and refactored related code. Added lots of tests and IR verification of optimizations.

Looks ok to me.

Roland.



From thartmann at openjdk.java.net  Mon May  4 15:22:33 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 4 May 2020 15:22:33 GMT
Subject: [lworld] [Rev 01] RFR: 8244339: [lworld] JIT support for inline
 types with abstract class supertypes
In-Reply-To: <OlvpvWNG7zuHvj_wgJlMFa-W8FgyK2r4F4amVkQrRVg=.31cc2057-be37-4e00-8891-d09e23f1fad3@github.com>
References: <OlvpvWNG7zuHvj_wgJlMFa-W8FgyK2r4F4amVkQrRVg=.31cc2057-be37-4e00-8891-d09e23f1fad3@github.com>
Message-ID: <IaSATUC2mh5MT1VuHMPmjwqoyMSQZJ-PlZKIDCbzGIo=.1f24ba7c-c9c3-4e86-a581-b2e775c0251b@github.com>

> C1 and C2 do not correctly handle and optimize inline types with abstract class supertypes and corresponding array
> covariance. I've fixed and refactored related code. Added lots of tests and IR verification of optimizations.

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  C1 implementation of acmp needs to check for abstract class as well

Thanks Roland!

This pull request has now been integrated.

Changeset: 6742fab8
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/6742fab8
Stats:     1017 lines in 18 files changed: 19 ins; 918 del; 80 mod

8244339: [lworld] JIT support for inline types with abstract class supertypes

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/33/files
  - new: https://git.openjdk.java.net/valhalla/pull/33/files/f58a1388..feefc748

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/33/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/33/webrev.00-01

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/33.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/33/head:pull/33

PR: https://git.openjdk.java.net/valhalla/pull/33


From hseigel at openjdk.java.net  Mon May  4 20:11:54 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 4 May 2020 20:11:54 GMT
Subject: [lworld] RFR: JDK-8243204 add class load time checking of abstract
 super classes =?UTF-8?B?b2bigKY=?=
Message-ID: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>

Please review this chagne.  It adds checks of super classes of inline classes.  It checks that an inline class's super
class is  either java.lang.Object or an abstract class.  And, if abstract, checks that the super, and its super, etc.
do not have instance fields, nor synchronized instance methods, or non-empty constructors, nor constructors with args.

The fix was tested with tiers 1 - 3.

-------------

Commit messages:
 - JDK-8243204 add class load time checking of abstract super classes of inline types

Changes: https://git.openjdk.java.net/valhalla/pull/34/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/34/webrev.00
  Stats: 1834 lines in 13 files changed: 1625 ins; 203 del; 6 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/34.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/34/head:pull/34

PR: https://git.openjdk.java.net/valhalla/pull/34


From fparain at openjdk.java.net  Mon May  4 21:27:32 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 4 May 2020 21:27:32 GMT
Subject: [lworld] RFR: JDK-8243204 add class load time checking of
 abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
Message-ID: <jIv0zLfB8Tho-O3rzjqkD_3yMVVaOavxb4pfXBdr6BA=.b49d0c7f-084b-4c5a-a58c-5926fa3f1dfd@github.com>

On Mon, 4 May 2020 20:04:38 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this chagne.  It adds checks of super classes of inline classes.  It checks that an inline class's super
> class is  either java.lang.Object or an abstract class.  And, if abstract, checks that the super, and its super, etc.
> do not have instance fields, nor synchronized instance methods, or non-empty constructors, nor constructors with args.
> The fix was tested with tiers 1 - 3.

Shouldn't `ClassFileParser::check_super_of_inline_type()` also check that no super classes implement the
`java.lang.IdentityObject` interface?

-------------

PR: https://git.openjdk.java.net/valhalla/pull/34


From srikanth.adayapalam at oracle.com  Tue May  5 05:36:27 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Tue, 5 May 2020 11:06:27 +0530
Subject: Memory layout benefits of inline classes
In-Reply-To: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
References: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
Message-ID: <e268c671-2ba4-da7a-e9df-f2e3e8a9d927@oracle.com>



On 27/04/20 1:14 pm, Swaranga Sarma wrote:
> The examples of the benefits of inline classes that I have seen in demos
> are things like high allocation of data classes in a tight loop. I was
> trying to understand how some of our existing code may benefit by using
> inline classes which is different from the examples seen. I have the
> following questions:
>
> 1. Optional: If we have a nullable members in a class, we would like to
> return an Optional<T> in the accessor for that member unless we have a
> reason to reduce the allocation. I recall somewhere that Optional might be
> an inline type in the future and this concern may no longer be valid. Is my
> understanding correct?

Sorry for the delay in responding.

It is the aspirational plan to be able to migrate certain JDK classes 
that are "value based classes" today. Prominent among them is Optional. 
Not all issues about the migration of such classes are solved today, but 
it is in the works.
>
> 2. CompletableFuture: Similar to Optional, is this a candidate for
> potentially turning into an inline type?

JDK classes that are migration candidates are often tagged as being 
"value-based" classes in their javadoc. I don't see CompletableFuture 
being identified as such - I didn't verify whether CompletableFuture 
fails to meet the criterial for being a value based class (See 
https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html) 


The short answer is: when we arrive at the bridge, we will take a call 
on what classes may be meaningfully, compatibly and profitably migrated.

Thus far I have heard of only Optional and various date and time related 
classes.

>
> 3. Regular data classes: In a lot of our code bases, we have data classes
> that look like:
> class Identifier {
>    final @NonNull Name name;
>    final @NonNull Id id;
> }
>
> class Name {
>    final @NonNull String value;
> }
>
> class Id {
>    final @NonNull String value;
> }
>
> We create instances like these and pass these around to other methods.
> Those methods access the necessary values using the access methods like
> identifier.name().value() or identifier.id().value(). These classes are
> probably good candidates for migrating to records. But I was also
> interested to understand if we also made them inline classes what memory
> layout benefits would we get. Would the pointer de-referencing problem go
> away in such cases?
>
> To put it in another way, most of our data classes boil down to Strings,
> and assuming String will not become an inline type, would there be any
> memory-layout benefits of making such classes inline?

Using your Id or Name classes as example, these instances could 
themselves be passed around as inline values - eliminating one level of 
pointer dereferencing (to reach the value reference). The string's 
content itself is going is (continue to involve) a level of dereferencing.

HTH,
Srikanth
>
> Regards
> Swaranga



From kasperni at gmail.com  Tue May  5 05:48:18 2020
From: kasperni at gmail.com (Kasper Nielsen)
Date: Tue, 5 May 2020 06:48:18 +0100
Subject: Memory layout benefits of inline classes
In-Reply-To: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
References: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
Message-ID: <CAPs6150rEpzn3g+kP_z9_VYghWVTJyOvWzTh-JwiJeWDOFYOGQ@mail.gmail.com>

> 2. CompletableFuture: Similar to Optional, is this a candidate for
> potentially turning into an inline type?

CompletableFuture is not a candidate. If you read [1]. You will see
that instance fields of an inline class must be marked ACC_FINAL.
And CompletableFuture contains 2 volatile instance fields.

/Kasper

[1] https://cr.openjdk.java.net/~briangoetz/valhalla/sov/03-vm-model.html


From orionllmain at gmail.com  Tue May  5 07:17:18 2020
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Tue, 5 May 2020 14:17:18 +0700
Subject: Memory layout benefits of inline classes
In-Reply-To: <e268c671-2ba4-da7a-e9df-f2e3e8a9d927@oracle.com>
References: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
 <e268c671-2ba4-da7a-e9df-f2e3e8a9d927@oracle.com>
Message-ID: <CAF2POUeJ3TqJE_8AQoFQv23JwSvmfQNVh9nrf3u0JZ-KZObAGQ@mail.gmail.com>

Can you please explain how can Optional become an inline class if inline
classes are non-nullable? Doesn't it mean that every code like this will
throw NPE after migration?

Optional<String> opt = null;


??, 5 ??? 2020 ?., 12:37 Srikanth <srikanth.adayapalam at oracle.com>:

>
>
> On 27/04/20 1:14 pm, Swaranga Sarma wrote:
> > The examples of the benefits of inline classes that I have seen in demos
> > are things like high allocation of data classes in a tight loop. I was
> > trying to understand how some of our existing code may benefit by using
> > inline classes which is different from the examples seen. I have the
> > following questions:
> >
> > 1. Optional: If we have a nullable members in a class, we would like to
> > return an Optional<T> in the accessor for that member unless we have a
> > reason to reduce the allocation. I recall somewhere that Optional might
> be
> > an inline type in the future and this concern may no longer be valid. Is
> my
> > understanding correct?
>
> Sorry for the delay in responding.
>
> It is the aspirational plan to be able to migrate certain JDK classes
> that are "value based classes" today. Prominent among them is Optional.
> Not all issues about the migration of such classes are solved today, but
> it is in the works.
> >
> > 2. CompletableFuture: Similar to Optional, is this a candidate for
> > potentially turning into an inline type?
>
> JDK classes that are migration candidates are often tagged as being
> "value-based" classes in their javadoc. I don't see CompletableFuture
> being identified as such - I didn't verify whether CompletableFuture
> fails to meet the criterial for being a value based class (See
>
> https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html)
>
>
>
> The short answer is: when we arrive at the bridge, we will take a call
> on what classes may be meaningfully, compatibly and profitably migrated.
>
> Thus far I have heard of only Optional and various date and time related
> classes.
>
> >
> > 3. Regular data classes: In a lot of our code bases, we have data classes
> > that look like:
> > class Identifier {
> >    final @NonNull Name name;
> >    final @NonNull Id id;
> > }
> >
> > class Name {
> >    final @NonNull String value;
> > }
> >
> > class Id {
> >    final @NonNull String value;
> > }
> >
> > We create instances like these and pass these around to other methods.
> > Those methods access the necessary values using the access methods like
> > identifier.name().value() or identifier.id().value(). These classes are
> > probably good candidates for migrating to records. But I was also
> > interested to understand if we also made them inline classes what memory
> > layout benefits would we get. Would the pointer de-referencing problem go
> > away in such cases?
> >
> > To put it in another way, most of our data classes boil down to Strings,
> > and assuming String will not become an inline type, would there be any
> > memory-layout benefits of making such classes inline?
>
> Using your Id or Name classes as example, these instances could
> themselves be passed around as inline values - eliminating one level of
> pointer dereferencing (to reach the value reference). The string's
> content itself is going is (continue to involve) a level of dereferencing.
>
> HTH,
> Srikanth
> >
> > Regards
> > Swaranga
>
>


From srikanth.adayapalam at oracle.com  Tue May  5 07:18:49 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Tue, 5 May 2020 12:48:49 +0530
Subject: Memory layout benefits of inline classes
In-Reply-To: <CAF2POUeJ3TqJE_8AQoFQv23JwSvmfQNVh9nrf3u0JZ-KZObAGQ@mail.gmail.com>
References: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
 <e268c671-2ba4-da7a-e9df-f2e3e8a9d927@oracle.com>
 <CAF2POUeJ3TqJE_8AQoFQv23JwSvmfQNVh9nrf3u0JZ-KZObAGQ@mail.gmail.com>
Message-ID: <be3866be-67a1-66d2-8224-cc4b4c2c63a4@oracle.com>



On 05/05/20 12:47 pm, Zheka Kozlov wrote:
> Can you please explain how can Optional become an inline class if 
> inline classes are non-nullable? Doesn't it mean that every code like 
> this will throw NPE after migration?
>
> Optional<String> opt = null;

Please study: 
https://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html
for the evolving design.

Srikanth

<https://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html>
>
>
> ??, 5 ??? 2020 ?., 12:37 Srikanth <srikanth.adayapalam at oracle.com 
> <mailto:srikanth.adayapalam at oracle.com>>:
>
>
>
>     On 27/04/20 1:14 pm, Swaranga Sarma wrote:
>     > The examples of the benefits of inline classes that I have seen
>     in demos
>     > are things like high allocation of data classes in a tight loop.
>     I was
>     > trying to understand how some of our existing code may benefit
>     by using
>     > inline classes which is different from the examples seen. I have the
>     > following questions:
>     >
>     > 1. Optional: If we have a nullable members in a class, we would
>     like to
>     > return an Optional<T> in the accessor for that member unless we
>     have a
>     > reason to reduce the allocation. I recall somewhere that
>     Optional might be
>     > an inline type in the future and this concern may no longer be
>     valid. Is my
>     > understanding correct?
>
>     Sorry for the delay in responding.
>
>     It is the aspirational plan to be able to migrate certain JDK classes
>     that are "value based classes" today. Prominent among them is
>     Optional.
>     Not all issues about the migration of such classes are solved
>     today, but
>     it is in the works.
>     >
>     > 2. CompletableFuture: Similar to Optional, is this a candidate for
>     > potentially turning into an inline type?
>
>     JDK classes that are migration candidates are often tagged as being
>     "value-based" classes in their javadoc. I don't see CompletableFuture
>     being identified as such - I didn't verify whether CompletableFuture
>     fails to meet the criterial for being a value based class (See
>     https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html)
>
>
>
>     The short answer is: when we arrive at the bridge, we will take a
>     call
>     on what classes may be meaningfully, compatibly and profitably
>     migrated.
>
>     Thus far I have heard of only Optional and various date and time
>     related
>     classes.
>
>     >
>     > 3. Regular data classes: In a lot of our code bases, we have
>     data classes
>     > that look like:
>     > class Identifier {
>     >? ? final @NonNull Name name;
>     >? ? final @NonNull Id id;
>     > }
>     >
>     > class Name {
>     >? ? final @NonNull String value;
>     > }
>     >
>     > class Id {
>     >? ? final @NonNull String value;
>     > }
>     >
>     > We create instances like these and pass these around to other
>     methods.
>     > Those methods access the necessary values using the access
>     methods like
>     > identifier.name <http://identifier.name>().value() or
>     identifier.id <http://identifier.id>().value(). These classes are
>     > probably good candidates for migrating to records. But I was also
>     > interested to understand if we also made them inline classes
>     what memory
>     > layout benefits would we get. Would the pointer de-referencing
>     problem go
>     > away in such cases?
>     >
>     > To put it in another way, most of our data classes boil down to
>     Strings,
>     > and assuming String will not become an inline type, would there
>     be any
>     > memory-layout benefits of making such classes inline?
>
>     Using your Id or Name classes as example, these instances could
>     themselves be passed around as inline values - eliminating one
>     level of
>     pointer dereferencing (to reach the value reference). The string's
>     content itself is going is (continue to involve) a level of
>     dereferencing.
>
>     HTH,
>     Srikanth
>     >
>     > Regards
>     > Swaranga
>



From sadayapalam at openjdk.java.net  Tue May  5 10:30:11 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 5 May 2020 10:30:11 GMT
Subject: [Integrated] [lworld] RFR: 8237072: [lworld] Add support for
 denoting and deriving the reference projection
In-Reply-To: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
References: <mcqZu6GzulP9gMnkFGEDtJIr4vz0Oo-Loexh4KPCdvQ=.bf6eb921-d567-4204-b9aa-a82db69e522d@github.com>
Message-ID: <Xb4ZW7OJmrU5WwOPU1s15E3Yp3bsWuk2QHi0puUxQlM=.f5e02b91-111d-4635-bf8e-47e1fd416ea1@github.com>

On Thu, 30 Apr 2020 04:27:10 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Hello Maurizio & Jim,
> 
>     May I request you to please review this patch for valhalla inline types support
> under the new scheme ? TIA.
> 
> I.   What does this patch do?
> II.  What can be skipped in the review?
> III. Recommended order for review.
> IV.  Known problems, limitations and deferred tasks.
> V.   Report to language designers on open problems.
> 
> I. What does this patch do:
> 
>     - From every inline class declaration V, derive two classes V and V.ref
>     - These two are subtypes at the VM level, but are related (only) by inline
>       widening conversion and narrowing conversion at the language level.
>     - The two types have the same fields and methods with the same shape and
>       accessibility rules.
>     - Add source level support for V.ref and V.val notation.
>     - Get rid of the experimental support for generics over values. Until we
>       figure out the full story with generics and inlines, carrying along this
>       experimental support is becoming untenable/unsustainable.
>     - Get rid of the experimental support added for noncovariant value arrays
>     - Get rid of LW2's "Nullable Projections" including the V? syntax
> 
> II. These files can be skipped as they simply revert change and align
>     with origin/master: (roll back V and V? nullable projections of LW2)
> 
>     JavacParser.java
>     AttrContext.java
>     JCTree.java
>     Pretty.java
>     Printer.java
>     RichDiagnosticsFormatter.java
>     TaskFactory.java
>     TreeCopier.java
>     TypePrinter.java
> 
> III. Recommended order for review:
> 
>     - Type.java, Symbol.java
> 
>             Look at the new internal APIs to query/compute various projections.
>             Every class type, class symbol, method and field support an API
>             to return the "other" projection i.e its doppleganger in the alternate
>             universe.
> 
>             Most crucially ClassSymbol.referenceProjection()
> 
>     - Attr.java:
> 
>             Source support for .ref/.val
> 
>     - MemberEnter.java:
>     - TypeEnter.java:
>     - TransTypes.java:
> 
>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
> 
>     - TransValues.java:
> 
>             Fold all V.ref.member accesses to ((V) V.ref).member access.
> 
>     - Resolve.java:
> 
>             Changes to make sure method look up works OK in a world where values are islands.
> 
>     - Types.java:
>   
>             Implement inline widening/narrowing relationship.
> 
>     - ProjectionRelationsTest.java:
> 
>             Verify all relationships between V and V.ref and V[] and V.ref[]
> 
>     - ClassWriter.java:
>             
>             Dual class generation scheme with subtyping relationship at the binary/VM level.
> 
>     - ClassReader.java:
> 
>             Merge the dual classes back, sever the subtyping relationship and make
>             them operate as a pair of classes that can convert to each other.
> 
>     - New tests:
>     
>             Most importantly ProjectionRelationsTest.java
> 
>     - Other files.
> 
>  
> IV. There are many known issues that have been deliberately deferred to a later iteration:
> 
>     - With Brian's consent I am using a simpler translation strategy than what is
>       outlined in the SoV documents. These are good enough for now, but when
>       VBC migration is undertaken, will have to enhanced.
>     - No support for ref-default and val-default classes yet.
>     - No support for class hierarchy sealing.
>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>     - Handling of .ref and .val is quick and dirty; Need revisit.
>     - The nest mate related attributes are not fully properly emitted as of now
>     - Need to verify that attributes from V are not carried over inadvertantly to
>       V$ref.class
>     - Class hierarchy walking in a world where inline types are islands calls for
>       a type switch. I have done this only in places uncovered by existing tests.
>       We need to go through various utility methods (similar to what is done in
>       Symbol.java and Resolve.java) to make sure these changes are consistently
>       applied.
>     - Diamond inference with value classes crashes now (implementation creates factory
>       methods, projections are missing and need to be created)
> 
> 
> V. Problems in the interplay of inlines types with generics and inference:
> 
>     Removing the experimental support for generics over values results in several
> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
> not compiling anymore.
> 
>     These expose some issues that feed into the language design. We need to evolve
> a short term answer (so that the JDK components tests that are impacted don't get
> blocked) and a long term one (the real solution)
> 
> Here is a snippet that captures these problems:
> import java.util.Arrays;
> 
> interface I {}
> 
> public inline class X implements I {
> 
>     int x = 10;
> 
>     void problem_01() {
>         X [] a1 = new X[0];
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>       
> /*
> error: incompatible types: inference variable T has incompatible bounds
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>                                          ^
>     lower bounds: X,Object
>     lower bounds: X$ref
>   where T,U are type-variables:
>     T extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
>     U extends Object declared in method <T,U>copyOf(U[],int,Class<? extends T[]>)
> 1 error
> */
>     }
> 
>     void foo(Class<? extends I> p) {}
> 
>     void problem_02() {
>         foo(X.class);
> /*
> error: incompatible types: Class<X> cannot be converted to Class<? extends I>
>         foo(X.class);
> */
>     }
> 
>     String data() {
>         return null;
>     }
> 
>     // Problem: 3, we infer a stream of X.ref's causing
>     // the method reference to not type check.
>     void unbound_lookup_with_projected_receiver() {
>         X [] a = new X[0];
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
> /*
> error: incompatible types: invalid method reference
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>                              ^
>     method data in class X cannot be applied to given types
>       required: no arguments
>       found:    X$ref
>       reason: actual and formal argument lists differ in length
> */
>     }
> 
>     void problem_04() {
> /*
>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>     Unsafe has been deprecated and marked for removal
>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>              ^
> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
> valueHeaderSize in class Unsafe cannot be applied to given types;
>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>                                          ^
>   required: Class<V>
>   found:    Class<Value2>
>   reason: inference variable V has incompatible bounds
>     equality constraints: Value2
>     lower bounds: Object
>   where V is a type-variable:
>     V extends Object declared in method <V>valueHeaderSize(Class<V>)
> */
>     }
> 
>     void problem_05() {
> /*
> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class<CAP#1> and
> Class<MyValue1$ref>
>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>                                                                          ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
> */
>     }
> 
>     public static void main(String [] args) {
>     }
> }

This pull request has now been integrated.

Changeset: a3a846d7
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a3a846d7
Stats:     1411 lines in 54 files changed: 259 ins; 1003 del; 149 mod

8237072: [lworld] Add support for denoting and deriving the reference projection

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32


From sadayapalam at openjdk.java.net  Tue May  5 11:02:29 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 5 May 2020 11:02:29 GMT
Subject: [Integrated] [lworld] RFR: 8243627: [lworld] Co-evolve
 jdk-valhalla tests along with JDK-8237072
In-Reply-To: <Dxs-o59SOv3UVspvK9H1kIbw6USP_nJrJm_PxWxomks=.31359e7e-4d93-42f0-8156-4a635ddc15ba@github.com>
References: <Dxs-o59SOv3UVspvK9H1kIbw6USP_nJrJm_PxWxomks=.31359e7e-4d93-42f0-8156-4a635ddc15ba@github.com>
Message-ID: <L1Ua027dVo1N9picuY2acLn1Sap0Pb_UisrHAlgKcsI=.d8803902-6f59-46b4-976b-9dd55bfe87c1@github.com>

On Mon, 27 Apr 2020 04:17:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Mandy,
> 
> May I request you to review these changes to jdk-valhalla tests ?
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and *after* JDK-8237072 itself is pushed.
> Thanks in advance.

This pull request has now been integrated.

Changeset: 9ef4318c
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9ef4318c
Stats:     52 lines in 11 files changed: 0 ins; 1 del; 51 mod

8243627: [lworld] Co-evolve jdk-valhalla tests along with JDK-8237072

Reviewed-by: mchung

-------------

PR: https://git.openjdk.java.net/valhalla/pull/27


From sadayapalam at openjdk.java.net  Tue May  5 11:07:56 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 5 May 2020 11:07:56 GMT
Subject: [Integrated] [lworld] RFR: 8243626: [lworld] Co-evolve
 hotspot-runtime tests along with JDK-8237072
In-Reply-To: <0Hi0qA2PXH8q4y4O2vc1QFN6AkxFGFC0CYKlBtX0jjE=.e2c7c703-afac-4181-ac0e-ab851ff1ce19@github.com>
References: <0Hi0qA2PXH8q4y4O2vc1QFN6AkxFGFC0CYKlBtX0jjE=.e2c7c703-afac-4181-ac0e-ab851ff1ce19@github.com>
Message-ID: <ikqV1hKvRrxo8ZKvrcqjh22Sjv3j2q_UiIXBCT-eNuI=.c2d38c84-9543-46b7-85b7-107c29684410@github.com>

On Mon, 27 Apr 2020 04:28:52 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Frederic,
> 
> May I request you to review these changes to hotspot runtime tests ?
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and after JDK-8237072 itself is pushed.
> Thanks in advance.

This pull request has now been integrated.

Changeset: 40289cfa
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/40289cfa
Stats:     57 lines in 12 files changed: 0 ins; 2 del; 55 mod

8243626: [lworld] Co-evolve hotspot-runtime tests along with JDK-8237072

Reviewed-by: fparain

-------------

PR: https://git.openjdk.java.net/valhalla/pull/28


From sadayapalam at openjdk.java.net  Tue May  5 11:12:03 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 5 May 2020 11:12:03 GMT
Subject: [Integrated] [lworld] RFR: 8243623: [lworld] Syntax and other
 mechanical changes in langtools tests for JDK-8237072
In-Reply-To: <JjVqYR9rSeH9Xl5FkZyZlA6n8PbRVZbgCIym-0E7es8=.6be3c2ab-0b68-43d8-96e5-ba9dc2aecabe@github.com>
References: <JjVqYR9rSeH9Xl5FkZyZlA6n8PbRVZbgCIym-0E7es8=.6be3c2ab-0b68-43d8-96e5-ba9dc2aecabe@github.com>
Message-ID: <nxwOtTero5kjpxUB9CVi4rISCSjEmxTKaTcRbz0AuOk=.6faa3e38-3390-40a2-b4d9-0624b6f7f361@github.com>

On Mon, 27 Apr 2020 04:42:21 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim,
> 
> May I request you to review these changes to langtools tests that anticipate and
> align with JDK-8237072 ? These changes are mechanical in nature and I decided it
> is best to separate them from the RFR for JDK-8237072 itself to help create sharper
> focus on the important pieces there. (Non-mechanical meaningful test changes with
> be included in that RFR itself)
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and after JDK-8237072 itself is pushed.
> Thanks in advance.

This pull request has now been integrated.

Changeset: 4c2f8bee
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/4c2f8bee
Stats:     90 lines in 26 files changed: 0 ins; 0 del; 90 mod

8243623: [lworld] Syntax and other mechanical changes in langtools tests for JDK-8237072

-------------

PR: https://git.openjdk.java.net/valhalla/pull/29


From sadayapalam at openjdk.java.net  Tue May  5 12:10:53 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 5 May 2020 12:10:53 GMT
Subject: [lworld] [Rev 02] RFR: 8243625: [lworld] Co-evolve
 hotspot-compiler tests along with JDK-8237072
In-Reply-To: <2jYS17UipWQiTMk13r-p6vALummTyBPG_sVhjQZODUw=.9dd3d917-37c8-45fd-9542-0102609b285f@github.com>
References: <2jYS17UipWQiTMk13r-p6vALummTyBPG_sVhjQZODUw=.9dd3d917-37c8-45fd-9542-0102609b285f@github.com>
Message-ID: <F8lZ0Nz33_dXeesODn7XRXLtIqUkhNgHzH5TYpt8dj8=.daeb517b-5db8-4597-aa1a-12a63fcdfe25@github.com>

> Tobias,
> 
> May I request you to review these changes to hotspot-compiler tests that anticipate
> and align with JDK-8237072 ? These changes are mechanical in nature and I decided it
> is best to separate them from the RFR for JDK-8237072 itself to help create sharper
> focus on the important pieces there.
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and after JDK-8237072 itself is pushed.
> Thanks in advance.

Srikanth Adayapalam has updated the pull request with a new target base due to a merge or a rebase. The pull request
now contains three commits:

 - Merge branch 'lworld' into JDK-8243625
 - Include fixes from Tobias for compilation failures.
 - 8243625: [lworld] Co-evolve hotspot-compiler tests along with JDK-8237072

This pull request has now been integrated.

Changeset: 08bfa8fe
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/08bfa8fe
Stats:     490 lines in 16 files changed: 0 ins; 11 del; 479 mod

8243625: [lworld] Co-evolve hotspot-compiler tests along with JDK-8237072

Reviewed-by: thartmann

-------------

Changes: https://git.openjdk.java.net/valhalla/pull/30/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/30/webrev.02
  Stats: 490 lines in 16 files changed: 11 ins; 0 del; 479 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/30/head:pull/30

PR: https://git.openjdk.java.net/valhalla/pull/30


From sadayapalam at openjdk.java.net  Wed May  6 13:37:55 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 6 May 2020 13:37:55 GMT
Subject: [lworld] RFR: 8244414: [lworld] Migrate Valhalla micro benchmarks
 suite to not use V? syntax
Message-ID: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>

Description of changes:

Hi Maruizio,

    Could you please review these assorted changes that block the build of Valhalla micro
benchmarks ? This is a culumative fix for JDK-8244414 and JDK-8244458

    You could skip a review of the benchmark source files themselves - these have only mechanical changes from V? to V.ref
    except for one case where there was a usage of Node?<K,V> with Node actually being an identity class. We don't support
    the transformed Node.ref<K,V> for identity classes, so I had to drop the '?'

Problems fixed:

    (i) Resolve.java: Diamond inference did not work for inline type constructors: Basically, the (static factory method
    equivalent) constructors synthesized during diamond inference did not have their reference projection counterparts and
    had to be paired up with them.

    (ii) Types.java: LUB computation in the presence of mixed values and non-values should first apply widening conversion.

    (iii) Enter.java: When we recompile files due to annotation processing rounds, discard
any prior state carried on by the reference projection so as to keep it in sync with its peer.
(A separate test will be added separately - for now building microbenchmarks is the test for this)

-------------

Commit messages:
 - Fix trailing white spaces.
 - 8244414: Migrate Valhalla micro benchmarks suite to not use V? syntax

Changes: https://git.openjdk.java.net/valhalla/pull/35/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/35/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244414
  Stats: 317 lines in 36 files changed: 139 ins; 0 del; 178 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/35.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/35/head:pull/35

PR: https://git.openjdk.java.net/valhalla/pull/35


From mcimadamore at openjdk.java.net  Wed May  6 14:01:18 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 May 2020 14:01:18 GMT
Subject: [lworld] RFR: 8244414: [lworld] Migrate Valhalla micro benchmarks
 suite to not use V? syntax
In-Reply-To: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
References: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
Message-ID: <DcAq3xVJrMyNgerbGThvC3kgZjoQvi57o-XOY4HQgJk=.8c677e4d-7ab3-4bcc-810b-ee4f83cfc776@github.com>

On Wed, 6 May 2020 13:26:31 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Description of changes:
> 
> Hi Maruizio,
> 
>     Could you please review these assorted changes that block the build of Valhalla micro
> benchmarks ? This is a culumative fix for JDK-8244414 and JDK-8244458
> 
>     You could skip a review of the benchmark source files themselves - these have only mechanical changes from V? to V.ref
>     except for one case where there was a usage of Node?<K,V> with Node actually being an identity class. We don't support
>     the transformed Node.ref<K,V> for identity classes, so I had to drop the '?'
> 
> Problems fixed:
> 
>     (i) Resolve.java: Diamond inference did not work for inline type constructors: Basically, the (static factory method
>     equivalent) constructors synthesized during diamond inference did not have their reference projection counterparts and
>     had to be paired up with them.
> 
>     (ii) Types.java: LUB computation in the presence of mixed values and non-values should first apply widening conversion.
> 
>     (iii) Enter.java: When we recompile files due to annotation processing rounds, discard
> any prior state carried on by the reference projection so as to keep it in sync with its peer.
> (A separate test will be added separately - for now building microbenchmarks is the test for this)

Added a couple of comments.

test/langtools/tools/javac/valhalla/lworld-values/LubWithInlines.java line 33:

> 32:
> 33: public class InlineDiamondTest<E> {
> 34:

This test seems the same as InlineDiamondTest...

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 4003:

> 4002:
> 4003:         boolean haveValues = false;
> 4004:         boolean haveRefs = false;

If the goal is to fix the behavior of conditional expression typing, I think the fix should happen outside lub(), more
specifically in Attr::condType

-------------

PR: https://git.openjdk.java.net/valhalla/pull/35


From sadayapalam at openjdk.java.net  Wed May  6 14:41:31 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 6 May 2020 14:41:31 GMT
Subject: [lworld] [Rev 01] RFR: 8244414: [lworld] Migrate Valhalla micro
 benchmarks suite to not use V? syntax
In-Reply-To: <DcAq3xVJrMyNgerbGThvC3kgZjoQvi57o-XOY4HQgJk=.8c677e4d-7ab3-4bcc-810b-ee4f83cfc776@github.com>
References: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
 <DcAq3xVJrMyNgerbGThvC3kgZjoQvi57o-XOY4HQgJk=.8c677e4d-7ab3-4bcc-810b-ee4f83cfc776@github.com>
Message-ID: <dc4lM-ttJdiQFKHffRB-2YF_sRndDPE-34JNx8WBiGg=.78b12381-13b8-47dd-b6b5-9fbd673af679@github.com>

On Wed, 6 May 2020 13:58:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix garbled test per review comment.
>
> test/langtools/tools/javac/valhalla/lworld-values/LubWithInlines.java line 33:
> 
>> 32:
>> 33: public class InlineDiamondTest<E> {
>> 34:
> 
> This test seems the same as InlineDiamondTest...

Hmmm. I have no idea how this garbling came about. It did exist in proper form some point as I can see from my backups!
Anyway thanks for catching this.!

-------------

PR: https://git.openjdk.java.net/valhalla/pull/35


From sadayapalam at openjdk.java.net  Wed May  6 14:41:30 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 6 May 2020 14:41:30 GMT
Subject: [lworld] [Rev 01] RFR: 8244414: [lworld] Migrate Valhalla micro
 benchmarks suite to not use V? syntax
In-Reply-To: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
References: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
Message-ID: <bTbQOH525rtqb-xZ6RyDe0_19goEez-gVNLQ4mCC1vI=.893e797b-9415-4bc9-b760-462169d96fc8@github.com>

> Description of changes:
> 
> Hi Maruizio,
> 
>     Could you please review these assorted changes that block the build of Valhalla micro
> benchmarks ? This is a culumative fix for JDK-8244414 and JDK-8244458
> 
>     You could skip a review of the benchmark source files themselves - these have only mechanical changes from V? to V.ref
>     except for one case where there was a usage of Node?<K,V> with Node actually being an identity class. We don't support
>     the transformed Node.ref<K,V> for identity classes, so I had to drop the '?'
> 
> Problems fixed:
> 
>     (i) Resolve.java: Diamond inference did not work for inline type constructors: Basically, the (static factory method
>     equivalent) constructors synthesized during diamond inference did not have their reference projection counterparts and
>     had to be paired up with them.
> 
>     (ii) Types.java: LUB computation in the presence of mixed values and non-values should first apply widening conversion.
> 
>     (iii) Enter.java: When we recompile files due to annotation processing rounds, discard
> any prior state carried on by the reference projection so as to keep it in sync with its peer.
> (A separate test will be added separately - for now building microbenchmarks is the test for this)

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Fix garbled test per review comment.

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/35/files
  - new: https://git.openjdk.java.net/valhalla/pull/35/files/990c0456..01d28c29

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/35/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/35/webrev.00-01

  Stats: 17 lines in 1 file changed: 0 ins; 4 del; 13 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/35.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/35/head:pull/35

PR: https://git.openjdk.java.net/valhalla/pull/35


From sadayapalam at openjdk.java.net  Wed May  6 14:41:58 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 6 May 2020 14:41:58 GMT
Subject: [lworld] [Rev 01] RFR: 8244414: [lworld] Migrate Valhalla micro
 benchmarks suite to not use V? syntax
In-Reply-To: <DcAq3xVJrMyNgerbGThvC3kgZjoQvi57o-XOY4HQgJk=.8c677e4d-7ab3-4bcc-810b-ee4f83cfc776@github.com>
References: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
 <DcAq3xVJrMyNgerbGThvC3kgZjoQvi57o-XOY4HQgJk=.8c677e4d-7ab3-4bcc-810b-ee4f83cfc776@github.com>
Message-ID: <_zggxjwWsFAXW70RcdMf_qhJd2Z-uG0clq6sH8o_y38=.92fb8ef4-43a6-4a07-b7f8-8bfcb756b317@github.com>

On Wed, 6 May 2020 13:58:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix garbled test per review comment.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 4003:
> 
>> 4002:
>> 4003:         boolean haveValues = false;
>> 4004:         boolean haveRefs = false;
> 
> If the goal is to fix the behavior of conditional expression typing, I think the fix should happen outside lub(), more
> specifically in Attr::condType

Hmm. - to me it looks more natural to push this down to the service. But I am open to bubbling this up to the client.
With your consent, I will combine this with the fix for JDK-8244513

-------------

PR: https://git.openjdk.java.net/valhalla/pull/35


From mcimadamore at openjdk.java.net  Wed May  6 16:26:07 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 May 2020 16:26:07 GMT
Subject: [lworld] [Rev 01] RFR: 8244414: [lworld] Migrate Valhalla micro
 benchmarks suite to not use V? syntax
In-Reply-To: <bTbQOH525rtqb-xZ6RyDe0_19goEez-gVNLQ4mCC1vI=.893e797b-9415-4bc9-b760-462169d96fc8@github.com>
References: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
 <bTbQOH525rtqb-xZ6RyDe0_19goEez-gVNLQ4mCC1vI=.893e797b-9415-4bc9-b760-462169d96fc8@github.com>
Message-ID: <nJhNpbf4ePAfoNFOLnB4RcFiIKvQw0L4Yh61ztK-F_I=.009a9c87-c45d-4055-91b1-8932bb939790@github.com>

On Wed, 6 May 2020 14:41:30 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Description of changes:
>> 
>> Hi Maruizio,
>> 
>>     Could you please review these assorted changes that block the build of Valhalla micro
>> benchmarks ? This is a culumative fix for JDK-8244414 and JDK-8244458
>> 
>>     You could skip a review of the benchmark source files themselves - these have only mechanical changes from V? to V.ref
>>     except for one case where there was a usage of Node?<K,V> with Node actually being an identity class. We don't support
>>     the transformed Node.ref<K,V> for identity classes, so I had to drop the '?'
>> 
>> Problems fixed:
>> 
>>     (i) Resolve.java: Diamond inference did not work for inline type constructors: Basically, the (static factory method
>>     equivalent) constructors synthesized during diamond inference did not have their reference projection counterparts and
>>     had to be paired up with them.
>> 
>>     (ii) Types.java: LUB computation in the presence of mixed values and non-values should first apply widening conversion.
>> 
>>     (iii) Enter.java: When we recompile files due to annotation processing rounds, discard
>> any prior state carried on by the reference projection so as to keep it in sync with its peer.
>> (A separate test will be added separately - for now building microbenchmarks is the test for this)
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix garbled test per review comment.

Looks good

-------------

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/35


From sadayapalam at openjdk.java.net  Wed May  6 16:29:29 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 6 May 2020 16:29:29 GMT
Subject: [Integrated] [lworld] RFR: 8244414: [lworld] Migrate Valhalla
 micro benchmarks suite to not use V? syntax
In-Reply-To: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
References: <t6kQ-qIxk_LLDmQudFsGEGaS-auWFccoYuQCMSSaUB0=.fa7aa26e-7c3d-4628-b441-b66db183a273@github.com>
Message-ID: <DgKbt6TFLbdEXXA2rRx3WLYt-PJ85Notwr8H-34FxXI=.9cdcfaac-492f-40a8-8d83-2e47593d951d@github.com>

On Wed, 6 May 2020 13:26:31 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Description of changes:
> 
> Hi Maruizio,
> 
>     Could you please review these assorted changes that block the build of Valhalla micro
> benchmarks ? This is a culumative fix for JDK-8244414 and JDK-8244458
> 
>     You could skip a review of the benchmark source files themselves - these have only mechanical changes from V? to V.ref
>     except for one case where there was a usage of Node?<K,V> with Node actually being an identity class. We don't support
>     the transformed Node.ref<K,V> for identity classes, so I had to drop the '?'
> 
> Problems fixed:
> 
>     (i) Resolve.java: Diamond inference did not work for inline type constructors: Basically, the (static factory method
>     equivalent) constructors synthesized during diamond inference did not have their reference projection counterparts and
>     had to be paired up with them.
> 
>     (ii) Types.java: LUB computation in the presence of mixed values and non-values should first apply widening conversion.
> 
>     (iii) Enter.java: When we recompile files due to annotation processing rounds, discard
> any prior state carried on by the reference projection so as to keep it in sync with its peer.
> (A separate test will be added separately - for now building microbenchmarks is the test for this)

This pull request has now been integrated.

Changeset: 72aa43eb
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/72aa43eb
Stats:     313 lines in 36 files changed: 0 ins; 135 del; 178 mod

8244414: [lworld] Migrate Valhalla micro benchmarks suite to not use V? syntax

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.java.net/valhalla/pull/35


From thartmann at openjdk.java.net  Wed May  6 16:14:59 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 6 May 2020 16:14:59 GMT
Subject: [lworld] RFR: 8244519: [lworld] C2 compilation fails with 'monitors
 must always exist for synchronized methods'
Message-ID: <pC3KwzBpIJ0d7Ro6L59J-APUgsBGtVmBrY85LNkao8A=.830f25c1-968e-4003-af92-5a91a30603a9@github.com>

C2 incorrectly assumes that the receiver of a synchronized method of an abstract class can be an inline type and
therefore adds a runtime check to the locking code (see 'can_be_value_type' check in
PhaseMacroExpand::expand_lock_node). While processing the JVMState of an uncommon trap emitted for that runtime check,
we assert because there is no monitor (yet) although the method is synchronized.

I've modified ciInstanceKlass::can_be_value_klass accordingly and added an to catch similar problems earlier. I've also
removed some dead code.

This fix includes the is_vanilla_constructor() fix from JDK-8243204.

-------------

Commit messages:
 - Including is_vanilla_constructor fix
 - 8244519: [lworld] C2 compilation fails with 'monitors must always exist for synchronized methods'

Changes: https://git.openjdk.java.net/valhalla/pull/36/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/36/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244519
  Stats: 45 lines in 4 files changed: 32 ins; 11 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/36.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/36/head:pull/36

PR: https://git.openjdk.java.net/valhalla/pull/36


From romanowski.mateusz at gmail.com  Wed May  6 17:29:48 2020
From: romanowski.mateusz at gmail.com (Mateusz Romanowski)
Date: Wed, 6 May 2020 17:29:48 +0000
Subject: Could the idea of null-default inline classes be revisited?
Message-ID: <CAL-BTSrACLfDkZohNsvHOw5imBXVktX70RTpcpvCfO2G4v6JPw@mail.gmail.com>

Hi,
The idea of null-default value types was raised years ago [1], however, I
believe it was dropped.

Considering that one of the reasons for Project Valhalla was, I believe,
not to have to choose between using safe abstractions (validating
constructor) and flat memory layout, replacing unsafe fields (ie.
firstName:Ljava/lang/String;, lastName:Ljava/lang/String;) with safe inline
value (ie. person:Qpkg/Person;) that wrap, should be easy without
surprising average developer.

Unfortunately, as Person.default cannot model real person, the developer
needs to learn new idiom for *some* inline types (comparing to default
value instead of null check) and learn that instanceof/cast no longer
rejects all impossible values.

Also, if generalizing the idea of migration of primitive type and its
wrapper class [2] into value and reference projection, we might consider
void/Void migration.

If void becomes alias for value projection java.lang.void and
java.lang.Void is its reference projection, then Void value set consists of
void.default and null. This would be a paradox, unless void.default becomes
null.


I think that those might be reasons for introducing L-envelope-using [3]
null-default inline types/classes.

Are there any chance for having vulls?

Thanks,
Mateusz Romanowski

[1] https://cr.openjdk.java.net/~jrose/values/nullable-values.html
[2] http://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html
[3]
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001288.html


From sergey.kuksenko at oracle.com  Wed May  6 17:50:42 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Wed, 6 May 2020 10:50:42 -0700
Subject: Memory layout benefits of inline classes
In-Reply-To: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
References: <CAGZD2TC5epeQ_cToPr8E_RMxstOE5TR=FXHXCWkTzKW8czOpJQ@mail.gmail.com>
Message-ID: <c4afe15e-da10-dcee-abcd-35cfd43322b4@oracle.com>

Hi,

I would suggest to look into this talk 
http://cr.openjdk.java.net/~skuksenko/valhalla/talk/vp.pdf

I hope some ideas/examples expressed there could be useful.

In general there are the following key areas where performance benefits 
of inline types arises:

- local variables in tight loops (eliminate allocations)

- dense memory layout

- GC write barriers elimination (the most undervalued point, but may 
give a huge impact)

- maybe something else....

Straightforward candidates are:

- All kinds of arithmetic/numeric types (Complex, java.lang.Number, 
vectors, ...)

- Short-lived intra-invocation objects. Like multy-value methods 
results/arguments, CompositeKey, Optional. Set of values wrapped with 
some united logic and splitting them gives performance, but extracting 
as separate class improve readability, maintenance.

- Dense data-structures. Currently we don't have direct candidates from 
JDK classlib. Searching to be continued. For example B-tree(or B+-tree) 
implementation should have benefits. Someday I'll implement a prototype 
to prove it.

- Cursor as replacement of Iterator

- to be continued.


On 4/27/20 12:44 AM, Swaranga Sarma wrote:
> The examples of the benefits of inline classes that I have seen in demos
> are things like high allocation of data classes in a tight loop. I was
> trying to understand how some of our existing code may benefit by using
> inline classes which is different from the examples seen. I have the
> following questions:
>
> 1. Optional: If we have a nullable members in a class, we would like to
> return an Optional<T> in the accessor for that member unless we have a
> reason to reduce the allocation. I recall somewhere that Optional might be
> an inline type in the future and this concern may no longer be valid. Is my
> understanding correct?
>
> 2. CompletableFuture: Similar to Optional, is this a candidate for
> potentially turning into an inline type?
>
> 3. Regular data classes: In a lot of our code bases, we have data classes
> that look like:
> class Identifier {
>    final @NonNull Name name;
>    final @NonNull Id id;
> }
>
> class Name {
>    final @NonNull String value;
> }
>
> class Id {
>    final @NonNull String value;
> }
>
> We create instances like these and pass these around to other methods.
> Those methods access the necessary values using the access methods like
> identifier.name().value() or identifier.id().value(). These classes are
> probably good candidates for migrating to records. But I was also
> interested to understand if we also made them inline classes what memory
> layout benefits would we get. Would the pointer de-referencing problem go
> away in such cases?
>
> To put it in another way, most of our data classes boil down to Strings,
> and assuming String will not become an inline type, would there be any
> memory-layout benefits of making such classes inline?
>
> Regards
> Swaranga


From john.r.rose at oracle.com  Wed May  6 19:46:26 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 6 May 2020 12:46:26 -0700
Subject: Could the idea of null-default inline classes be revisited?
In-Reply-To: <CAL-BTSrACLfDkZohNsvHOw5imBXVktX70RTpcpvCfO2G4v6JPw@mail.gmail.com>
References: <CAL-BTSrACLfDkZohNsvHOw5imBXVktX70RTpcpvCfO2G4v6JPw@mail.gmail.com>
Message-ID: <B54C05B2-2967-4B75-B339-54F92B4660A0@oracle.com>

Our current model is much simpler and more manageable
than the one outlined in [1] and handles most use cases of null.
But, as you point out, it does allow V.default and null to
co-exist as points in the type of V?s box type, just as (int)0
coexists with null in the type Integer.  This is just one of
the simplifications that comes from admitting that there
are two (named) types associated with an inline class V,
the inline type itself V.val  and its box/reference type V.ref.

(To review: V.val translates to an inline class class file,
while V.ref translates to a non-inline abstract class file.
The two types are sealed together as nest-mates.  The
JVM gives them distinct names.  The owner of the
?good name? V is up for grabs in the translation strategy.
The result is that V.val : V.ref :: int : Integer.  We have
dropped the ?clever? technique of deriving both types
from one classfile, because it buys us some stuff.  There
are many more details not worth going into here.)

You are suggesting that the current model falls short
in cases where the author of an inline type V really,
really doesn?t want null (in V.ref) to be distinct from
V.default (in both V.val and V.ref).  Obviously, the
only place where the distinction shows up is not in
V.val but V.ref.  That suggests that you?d like for the
boxing operation (from V.val to V.ref) to include an
optional step to map (V.val)V.default to (V.ref)null,
instead of a non-null reference which boxes the
bit-pattern of V.default.

Any decision like this has deep and far-reaching
consequences.  One such consequence here is that,
even if some software module assumes that null is
disjoint from any V instance, the author of V can
subvert that assumption by converting one of the
V.val points to null (when boxed to V.ref).  Perhaps
this is a decision the author can make safely and
locally, within the bounds of V?s encapsulation,
but it is hard to predict the long-term effects of
?hiding? the default value of V.

Another consequence is that the JVM has to very
carefully ensure that no instance of (V.val)V.default
ever escapes into the larger type space of Object or
V.ref.  This has a cost and a probable bug tail.

Another consequence is that unboxing null to V.val
would have to detect the null and substitute a value
(V.default, the ?vull? value for V).  That might seem
straightforward, but it?s not; we?d have to define all
the places where NPE would happen on such an
attempted unboxing, and where silent substitution
of V.default would happen.  That?s not only complicated,
but likely to lead to a long chain of surprises for
end users.  They would go both ways:  ?Hey, what?s
the NPE in my program?  I know I constructed that
value correctly!? Or, ?Hey, why did my program
silently accept a method call on that uninitialized
pointer? It took me days to track down that bug!?

Not all the machinery of [1] would have to be activated
to implement your request, because some features of
the two-type model would allow us to do better book
keeping.  For example, V.ref.default would be null,
while V.val.default would be a real value, not a real
null.  But there is still plenty of complexity in any
of the known solutions to this request.

While I recognize that box-deafult-to-null would be
helpful for some use cases, it?s not just a simple add-on.
I?m inclined to leave it as a possible future extension,
to be opted into by future inline classes, if the feature
gets implemented.

For now, the choice is pretty straightforward:  If you
need null as a value in a variable of type V, use V.ref.
If you need flatness in the variable, use V.val.  Choose
one.

? John

On May 6, 2020, at 10:29 AM, Mateusz Romanowski <romanowski.mateusz at gmail.com> wrote:
> 
> Hi,
> The idea of null-default value types was raised years ago [1], however, I
> believe it was dropped.
> 
> Considering that one of the reasons for Project Valhalla was, I believe,
> not to have to choose between using safe abstractions (validating
> constructor) and flat memory layout, replacing unsafe fields (ie.
> firstName:Ljava/lang/String;, lastName:Ljava/lang/String;) with safe inline
> value (ie. person:Qpkg/Person;) that wrap, should be easy without
> surprising average developer.
> 
> Unfortunately, as Person.default cannot model real person, the developer
> needs to learn new idiom for *some* inline types (comparing to default
> value instead of null check) and learn that instanceof/cast no longer
> rejects all impossible values.
> 
> Also, if generalizing the idea of migration of primitive type and its
> wrapper class [2] into value and reference projection, we might consider
> void/Void migration.
> 
> If void becomes alias for value projection java.lang.void and
> java.lang.Void is its reference projection, then Void value set consists of
> void.default and null. This would be a paradox, unless void.default becomes
> null.
> 
> 
> I think that those might be reasons for introducing L-envelope-using [3]
> null-default inline types/classes.
> 
> Are there any chance for having vulls?
> 
> Thanks,
> Mateusz Romanowski
> 
> [1] https://cr.openjdk.java.net/~jrose/values/nullable-values.html
> [2] http://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html
> [3]
> https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001288.html



From john.r.rose at oracle.com  Wed May  6 19:51:34 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 6 May 2020 12:51:34 -0700
Subject: Could the idea of null-default inline classes be revisited?
In-Reply-To: <B54C05B2-2967-4B75-B339-54F92B4660A0@oracle.com>
References: <CAL-BTSrACLfDkZohNsvHOw5imBXVktX70RTpcpvCfO2G4v6JPw@mail.gmail.com>
 <B54C05B2-2967-4B75-B339-54F92B4660A0@oracle.com>
Message-ID: <F988CF72-3A07-48AC-9B14-62BDAC9E7325@oracle.com>

On May 6, 2020, at 12:46 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> For now, the choice is pretty straightforward:  If you
> need null as a value in a variable of type V, use V.ref.
> If you need flatness in the variable, use V.val.  Choose
> one.

P.S. If you need both, encapsulate the field as a V.val
and transcode between V.default and (V.ref)null in
access methods and constructors.  If you need naked
fields *and* flatness *and* null, you are still out of luck.

Sadly, record types won?t help with this, thought perhaps
there?s some limited call for boxing/unboxing relations
between a record?s internal and external field types;
that?s another can of worms.  Use Java?s class-based
data abstraction!

From forax at univ-mlv.fr  Wed May  6 20:49:21 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 6 May 2020 22:49:21 +0200 (CEST)
Subject: compiler issue with after the recent changes in the compiler
Message-ID: <776674872.260.1588798161685.JavaMail.zimbra@u-pem.fr>

Hi Srikanth,
using a version compiled yesterday, javac struggle with my code :)
(i believe the issue is when compiling the method iterator() but i may be wrong)

Also the "printing javac parameters" at the end looks like a debug knob not being turn off.

regards,
R?mi

$ javac Array.java
java.lang.NullPointerException
	at jdk.compiler/com.sun.tools.javac.code.Types$13.visitClassType(Types.java:2331)
	at jdk.compiler/com.sun.tools.javac.code.Types$13.visitClassType(Types.java:2318)
	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1065)
	at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4951)
	at jdk.compiler/com.sun.tools.javac.code.Types.memberType(Types.java:2315)
	at jdk.compiler/com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:589)
	at jdk.compiler/com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1597)
	at jdk.compiler/com.sun.tools.javac.comp.Resolve.findDiamond(Resolve.java:2952)
	at jdk.compiler/com.sun.tools.javac.comp.Resolve$13.doLookup(Resolve.java:2898)
	at jdk.compiler/com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:3367)
	at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3617)
	at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3602)
	at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveDiamond(Resolve.java:2894)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2728)
	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1827)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitReturn(Attr.java:2316)
	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1684)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:781)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1456)
	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1044)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1239)
	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:890)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5308)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5190)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5112)
	at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5057)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1348)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
	at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:316)
	at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
	at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
	at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
printing javac parameters to: /tmp/val-bug/javac.20200506_223738.args


---

import static java.util.stream.IntStream.range;

import java.util.Arrays;
import java.util.Collection;
import java.util.Comparator;
import java.util.Iterator;
import java.util.List;
import java.util.ListIterator;
import java.util.NoSuchElementException;
import java.util.Objects;
import java.util.Spliterator;
import java.util.Spliterators;
import java.util.function.Consumer;
import java.util.function.Predicate;
import java.util.function.UnaryOperator;

@__inline__
public final class Array<E> implements List<E> {
  private final E[] elements;

  private Array(E[] elements) {
    this.elements = elements;
  }

  public static <E> Array<E> wrap(E[] elements) {
    return new Array<>(Objects.requireNonNull(elements));
  }

  @SafeVarargs
  public static <E> Array<E> of(E... elements) {
    return wrap(elements);
  }

  public int length() {
    return elements.length;
  }
  
  @Override
  public boolean equals(Object obj) {
    if (obj instanceof Array) {
      var array = (Array<?>)obj;
      return Arrays.equals(elements, array.elements);
    }
    if (obj instanceof List) {
      return equalsList((List<?>)obj);
    }
    return false;
  }
  private boolean equalsList(List<?> list) {
    var it = list.iterator();
    for(var element: elements) {
      if (!it.hasNext()) {
        return false;
      }
      var other = it.next();
      if (!Objects.equals(element, other)) {
        return false;
      }
    }
    return !it.hasNext();
  }
  
  @Override
  public int hashCode() {
    return Arrays.hashCode(elements);
  }
  
  @Override
  public String toString() {
    return Arrays.toString(elements);
  }

  @Override
  public int size() {
    return elements.length;
  }

  @Override
  public boolean isEmpty() {
    return elements.length == 0;
  }

  @Override
  public E get(int index) {
    return elements[index];
  }
  
  @Override
  public E set(int index, E element) {
    var old = elements[index];
    elements[index] = element;
    return old;
  }
  
  @Override
  public int indexOf(Object o) {
    var length = elements.length;
    return range(0, length).filter(i -> Objects.equals(o, elements[i])).findFirst()
        .orElse(-1);
  }
  
  @Override
  public int lastIndexOf(Object o) {
    for(var i = elements.length; --i >= 0;) {
      if (Objects.equals(o, elements[i])) {
        return i;
      }
    }
    return -1;
  }

  @Override
  public boolean contains(Object o) {
    return Arrays.stream(elements).anyMatch(Predicate.isEqual(o));
  }
  
  @Override
  public boolean containsAll(Collection<?> collection) {
    return collection.stream().allMatch(this::contains);
  }

  @Override
  public Iterator<E> iterator() {
    return new Iterator<>() {
      private int index;
      
      @Override
      public boolean hasNext() {
        return index < elements.length;
      }
      @Override
      public E next() {
        if (!hasNext()) {
          throw new NoSuchElementException("no such element");
        }
        return elements[index++];
      }
    };
  }
  
  @Override
  public ListIterator<E> listIterator() {
    return listIterator(0);
  }
  @Override
  public ListIterator<E> listIterator(int index) {
    return Arrays.asList(elements).listIterator(index);
  }
  @Override
  public List<E> subList(int fromIndex, int toIndex) {
    return Arrays.asList(elements).subList(fromIndex, toIndex);
  }
  
  @Override
  public Object[] toArray() {
    return Arrays.copyOf(elements, elements.length, Object[].class);
  }

  @Override
  @SuppressWarnings("unchecked")
  public <T> T[] toArray(T[] a) {
    var elements = this.elements;
    var length = elements.length;
    if (a.length < length) {
      return (T[])Arrays.copyOf(elements, length, a.getClass());
    }
    System.arraycopy(elements, 0, a, 0, length);
    if (a.length > length) {
      a[length] = null;
    }
    return a;
  }

  @Override
  public boolean add(E e) {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public void add(int index, E element) {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public boolean addAll(Collection<? extends E> c) {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public boolean addAll(int index, Collection<? extends E> c) {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public void clear() {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public E remove(int index) {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public boolean remove(Object o) {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public boolean removeAll(Collection<?> c) {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public boolean retainAll(Collection<?> c) {
    throw new UnsupportedOperationException("operation not supported");
  }
  @Override
  public boolean removeIf(Predicate<? super E> filter) {
    throw new UnsupportedOperationException("operation not supported");
  }
  
  @Override
  public void forEach(Consumer<? super E> action) {
    for(var element: elements) {
      action.accept(element);
    }
  }
  
  @Override
  public void replaceAll(UnaryOperator<E> operator) {
    for(var i = 0; i < elements.length; i++) {
      elements[i] = operator.apply(elements[i]);
    }
  }
  
  @Override
  public void sort(Comparator<? super E> comparator) {
    Arrays.sort(elements, comparator);
  }
  
  @Override
  public Spliterator<E> spliterator() {
    return Spliterators.spliterator(elements, Spliterator.ORDERED);
  }
}


From forax at univ-mlv.fr  Wed May  6 20:56:34 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 6 May 2020 22:56:34 +0200 (CEST)
Subject: compiler issue with after the recent changes in the compiler
In-Reply-To: <776674872.260.1588798161685.JavaMail.zimbra@u-pem.fr>
References: <776674872.260.1588798161685.JavaMail.zimbra@u-pem.fr>
Message-ID: <1413014100.1392.1588798594366.JavaMail.zimbra@u-pem.fr>

Nope,
the bug is in wrap(), using E instead of the diamond and javac compiles
  public static <E> Array<E> wrap(E[] elements) {
    return new Array<>(Objects.requireNonNull(elements));   // crash
    return new Array<E>(Objects.requireNonNull(elements));  // compile
  }

R?mi

----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> ?: "Srikanth Adayapalam" <sadayapalam at openjdk.java.net>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Mercredi 6 Mai 2020 22:49:21
> Objet: compiler issue with after the recent changes in the compiler

> Hi Srikanth,
> using a version compiled yesterday, javac struggle with my code :)
> (i believe the issue is when compiling the method iterator() but i may be wrong)
> 
> Also the "printing javac parameters" at the end looks like a debug knob not
> being turn off.
> 
> regards,
> R?mi
> 
> $ javac Array.java
> java.lang.NullPointerException
>	at
>	jdk.compiler/com.sun.tools.javac.code.Types$13.visitClassType(Types.java:2331)
>	at
>	jdk.compiler/com.sun.tools.javac.code.Types$13.visitClassType(Types.java:2318)
>	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1065)
>	at
>	jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4951)
>	at jdk.compiler/com.sun.tools.javac.code.Types.memberType(Types.java:2315)
>	at
>	jdk.compiler/com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:589)
>	at jdk.compiler/com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1597)
>	at jdk.compiler/com.sun.tools.javac.comp.Resolve.findDiamond(Resolve.java:2952)
>	at jdk.compiler/com.sun.tools.javac.comp.Resolve$13.doLookup(Resolve.java:2898)
>	at
>	jdk.compiler/com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:3367)
>	at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3617)
>	at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3602)
>	at
>	jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveDiamond(Resolve.java:2894)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2728)
>	at
>	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1827)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitReturn(Attr.java:2316)
>	at
>	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1684)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:781)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1456)
>	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1044)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1239)
>	at
>	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:890)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5308)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5190)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5112)
>	at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5057)
>	at
>	jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1348)
>	at
>	jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
>	at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:316)
>	at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>	at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>	at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
> printing javac parameters to: /tmp/val-bug/javac.20200506_223738.args
> 
> 
> ---
> 
> import static java.util.stream.IntStream.range;
> 
> import java.util.Arrays;
> import java.util.Collection;
> import java.util.Comparator;
> import java.util.Iterator;
> import java.util.List;
> import java.util.ListIterator;
> import java.util.NoSuchElementException;
> import java.util.Objects;
> import java.util.Spliterator;
> import java.util.Spliterators;
> import java.util.function.Consumer;
> import java.util.function.Predicate;
> import java.util.function.UnaryOperator;
> 
> @__inline__
> public final class Array<E> implements List<E> {
>  private final E[] elements;
> 
>  private Array(E[] elements) {
>    this.elements = elements;
>  }
> 
>  public static <E> Array<E> wrap(E[] elements) {
>    return new Array<>(Objects.requireNonNull(elements));
>  }
> 
>  @SafeVarargs
>  public static <E> Array<E> of(E... elements) {
>    return wrap(elements);
>  }
> 
>  public int length() {
>    return elements.length;
>  }
>  
>  @Override
>  public boolean equals(Object obj) {
>    if (obj instanceof Array) {
>      var array = (Array<?>)obj;
>      return Arrays.equals(elements, array.elements);
>    }
>    if (obj instanceof List) {
>      return equalsList((List<?>)obj);
>    }
>    return false;
>  }
>  private boolean equalsList(List<?> list) {
>    var it = list.iterator();
>    for(var element: elements) {
>      if (!it.hasNext()) {
>        return false;
>      }
>      var other = it.next();
>      if (!Objects.equals(element, other)) {
>        return false;
>      }
>    }
>    return !it.hasNext();
>  }
>  
>  @Override
>  public int hashCode() {
>    return Arrays.hashCode(elements);
>  }
>  
>  @Override
>  public String toString() {
>    return Arrays.toString(elements);
>  }
> 
>  @Override
>  public int size() {
>    return elements.length;
>  }
> 
>  @Override
>  public boolean isEmpty() {
>    return elements.length == 0;
>  }
> 
>  @Override
>  public E get(int index) {
>    return elements[index];
>  }
>  
>  @Override
>  public E set(int index, E element) {
>    var old = elements[index];
>    elements[index] = element;
>    return old;
>  }
>  
>  @Override
>  public int indexOf(Object o) {
>    var length = elements.length;
>    return range(0, length).filter(i -> Objects.equals(o, elements[i])).findFirst()
>        .orElse(-1);
>  }
>  
>  @Override
>  public int lastIndexOf(Object o) {
>    for(var i = elements.length; --i >= 0;) {
>      if (Objects.equals(o, elements[i])) {
>        return i;
>      }
>    }
>    return -1;
>  }
> 
>  @Override
>  public boolean contains(Object o) {
>    return Arrays.stream(elements).anyMatch(Predicate.isEqual(o));
>  }
>  
>  @Override
>  public boolean containsAll(Collection<?> collection) {
>    return collection.stream().allMatch(this::contains);
>  }
> 
>  @Override
>  public Iterator<E> iterator() {
>    return new Iterator<>() {
>      private int index;
>      
>      @Override
>      public boolean hasNext() {
>        return index < elements.length;
>      }
>      @Override
>      public E next() {
>        if (!hasNext()) {
>          throw new NoSuchElementException("no such element");
>        }
>        return elements[index++];
>      }
>    };
>  }
>  
>  @Override
>  public ListIterator<E> listIterator() {
>    return listIterator(0);
>  }
>  @Override
>  public ListIterator<E> listIterator(int index) {
>    return Arrays.asList(elements).listIterator(index);
>  }
>  @Override
>  public List<E> subList(int fromIndex, int toIndex) {
>    return Arrays.asList(elements).subList(fromIndex, toIndex);
>  }
>  
>  @Override
>  public Object[] toArray() {
>    return Arrays.copyOf(elements, elements.length, Object[].class);
>  }
> 
>  @Override
>  @SuppressWarnings("unchecked")
>  public <T> T[] toArray(T[] a) {
>    var elements = this.elements;
>    var length = elements.length;
>    if (a.length < length) {
>      return (T[])Arrays.copyOf(elements, length, a.getClass());
>    }
>    System.arraycopy(elements, 0, a, 0, length);
>    if (a.length > length) {
>      a[length] = null;
>    }
>    return a;
>  }
> 
>  @Override
>  public boolean add(E e) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public void add(int index, E element) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public boolean addAll(Collection<? extends E> c) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public boolean addAll(int index, Collection<? extends E> c) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public void clear() {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public E remove(int index) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public boolean remove(Object o) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public boolean removeAll(Collection<?> c) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public boolean retainAll(Collection<?> c) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  @Override
>  public boolean removeIf(Predicate<? super E> filter) {
>    throw new UnsupportedOperationException("operation not supported");
>  }
>  
>  @Override
>  public void forEach(Consumer<? super E> action) {
>    for(var element: elements) {
>      action.accept(element);
>    }
>  }
>  
>  @Override
>  public void replaceAll(UnaryOperator<E> operator) {
>    for(var i = 0; i < elements.length; i++) {
>      elements[i] = operator.apply(elements[i]);
>    }
>  }
>  
>  @Override
>  public void sort(Comparator<? super E> comparator) {
>    Arrays.sort(elements, comparator);
>  }
>  
>  @Override
>  public Spliterator<E> spliterator() {
>    return Spliterators.spliterator(elements, Spliterator.ORDERED);
>  }
> }


From srikanth.adayapalam at oracle.com  Wed May  6 23:45:36 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Thu, 7 May 2020 05:15:36 +0530
Subject: compiler issue with after the recent changes in the compiler
In-Reply-To: <1413014100.1392.1588798594366.JavaMail.zimbra@u-pem.fr>
References: <776674872.260.1588798161685.JavaMail.zimbra@u-pem.fr>
 <1413014100.1392.1588798594366.JavaMail.zimbra@u-pem.fr>
Message-ID: <6201899f-ab4e-de97-cc84-7436133afe0e@oracle.com>



On 07/05/20 2:26 am, Remi Forax wrote:
> Nope,
> the bug is in wrap(), using E instead of the diamond and javac compiles
>    public static <E> Array<E> wrap(E[] elements) {
>      return new Array<>(Objects.requireNonNull(elements));   // crash
>      return new Array<E>(Objects.requireNonNull(elements));  // compile
>    }

Hello Remi,

Can you try again ? This was an acknowledged problem as of 
https://github.com/openjdk/valhalla/pull/32 which subsequently got 
resolved through https://bugs.openjdk.java.net/browse/JDK-8244458 (which 
itself got subsumed and cumulatively fixed via JDK-8244414)

I am able to compile the file Array.java you have attached without a 
crash. I'll add it to javac's tests anyways in a future commit.

Thanks!
Srikanth
> R?mi
>
> ----- Mail original -----
>> De: "Remi Forax" <forax at univ-mlv.fr>
>> ?: "Srikanth Adayapalam" <sadayapalam at openjdk.java.net>
>> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoy?: Mercredi 6 Mai 2020 22:49:21
>> Objet: compiler issue with after the recent changes in the compiler
>> Hi Srikanth,
>> using a version compiled yesterday, javac struggle with my code :)
>> (i believe the issue is when compiling the method iterator() but i may be wrong)
>>
>> Also the "printing javac parameters" at the end looks like a debug knob not
>> being turn off.
>>
>> regards,
>> R?mi
>>
>> $ javac Array.java
>> java.lang.NullPointerException
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.code.Types$13.visitClassType(Types.java:2331)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.code.Types$13.visitClassType(Types.java:2318)
>> 	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1065)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4951)
>> 	at jdk.compiler/com.sun.tools.javac.code.Types.memberType(Types.java:2315)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:589)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1597)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve.findDiamond(Resolve.java:2952)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve$13.doLookup(Resolve.java:2898)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:3367)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3617)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3602)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveDiamond(Resolve.java:2894)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2728)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1827)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitReturn(Attr.java:2316)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1684)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:781)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1456)
>> 	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1044)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1239)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:890)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5308)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5190)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5112)
>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5057)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1348)
>> 	at
>> 	jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
>> 	at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:316)
>> 	at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>> 	at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>> 	at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>> printing javac parameters to: /tmp/val-bug/javac.20200506_223738.args
>>
>>
>> ---
>>
>> import static java.util.stream.IntStream.range;
>>
>> import java.util.Arrays;
>> import java.util.Collection;
>> import java.util.Comparator;
>> import java.util.Iterator;
>> import java.util.List;
>> import java.util.ListIterator;
>> import java.util.NoSuchElementException;
>> import java.util.Objects;
>> import java.util.Spliterator;
>> import java.util.Spliterators;
>> import java.util.function.Consumer;
>> import java.util.function.Predicate;
>> import java.util.function.UnaryOperator;
>>
>> @__inline__
>> public final class Array<E> implements List<E> {
>>   private final E[] elements;
>>
>>   private Array(E[] elements) {
>>     this.elements = elements;
>>   }
>>
>>   public static <E> Array<E> wrap(E[] elements) {
>>     return new Array<>(Objects.requireNonNull(elements));
>>   }
>>
>>   @SafeVarargs
>>   public static <E> Array<E> of(E... elements) {
>>     return wrap(elements);
>>   }
>>
>>   public int length() {
>>     return elements.length;
>>   }
>>   
>>   @Override
>>   public boolean equals(Object obj) {
>>     if (obj instanceof Array) {
>>       var array = (Array<?>)obj;
>>       return Arrays.equals(elements, array.elements);
>>     }
>>     if (obj instanceof List) {
>>       return equalsList((List<?>)obj);
>>     }
>>     return false;
>>   }
>>   private boolean equalsList(List<?> list) {
>>     var it = list.iterator();
>>     for(var element: elements) {
>>       if (!it.hasNext()) {
>>         return false;
>>       }
>>       var other = it.next();
>>       if (!Objects.equals(element, other)) {
>>         return false;
>>       }
>>     }
>>     return !it.hasNext();
>>   }
>>   
>>   @Override
>>   public int hashCode() {
>>     return Arrays.hashCode(elements);
>>   }
>>   
>>   @Override
>>   public String toString() {
>>     return Arrays.toString(elements);
>>   }
>>
>>   @Override
>>   public int size() {
>>     return elements.length;
>>   }
>>
>>   @Override
>>   public boolean isEmpty() {
>>     return elements.length == 0;
>>   }
>>
>>   @Override
>>   public E get(int index) {
>>     return elements[index];
>>   }
>>   
>>   @Override
>>   public E set(int index, E element) {
>>     var old = elements[index];
>>     elements[index] = element;
>>     return old;
>>   }
>>   
>>   @Override
>>   public int indexOf(Object o) {
>>     var length = elements.length;
>>     return range(0, length).filter(i -> Objects.equals(o, elements[i])).findFirst()
>>         .orElse(-1);
>>   }
>>   
>>   @Override
>>   public int lastIndexOf(Object o) {
>>     for(var i = elements.length; --i >= 0;) {
>>       if (Objects.equals(o, elements[i])) {
>>         return i;
>>       }
>>     }
>>     return -1;
>>   }
>>
>>   @Override
>>   public boolean contains(Object o) {
>>     return Arrays.stream(elements).anyMatch(Predicate.isEqual(o));
>>   }
>>   
>>   @Override
>>   public boolean containsAll(Collection<?> collection) {
>>     return collection.stream().allMatch(this::contains);
>>   }
>>
>>   @Override
>>   public Iterator<E> iterator() {
>>     return new Iterator<>() {
>>       private int index;
>>       
>>       @Override
>>       public boolean hasNext() {
>>         return index < elements.length;
>>       }
>>       @Override
>>       public E next() {
>>         if (!hasNext()) {
>>           throw new NoSuchElementException("no such element");
>>         }
>>         return elements[index++];
>>       }
>>     };
>>   }
>>   
>>   @Override
>>   public ListIterator<E> listIterator() {
>>     return listIterator(0);
>>   }
>>   @Override
>>   public ListIterator<E> listIterator(int index) {
>>     return Arrays.asList(elements).listIterator(index);
>>   }
>>   @Override
>>   public List<E> subList(int fromIndex, int toIndex) {
>>     return Arrays.asList(elements).subList(fromIndex, toIndex);
>>   }
>>   
>>   @Override
>>   public Object[] toArray() {
>>     return Arrays.copyOf(elements, elements.length, Object[].class);
>>   }
>>
>>   @Override
>>   @SuppressWarnings("unchecked")
>>   public <T> T[] toArray(T[] a) {
>>     var elements = this.elements;
>>     var length = elements.length;
>>     if (a.length < length) {
>>       return (T[])Arrays.copyOf(elements, length, a.getClass());
>>     }
>>     System.arraycopy(elements, 0, a, 0, length);
>>     if (a.length > length) {
>>       a[length] = null;
>>     }
>>     return a;
>>   }
>>
>>   @Override
>>   public boolean add(E e) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public void add(int index, E element) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public boolean addAll(Collection<? extends E> c) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public boolean addAll(int index, Collection<? extends E> c) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public void clear() {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public E remove(int index) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public boolean remove(Object o) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public boolean removeAll(Collection<?> c) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public boolean retainAll(Collection<?> c) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   @Override
>>   public boolean removeIf(Predicate<? super E> filter) {
>>     throw new UnsupportedOperationException("operation not supported");
>>   }
>>   
>>   @Override
>>   public void forEach(Consumer<? super E> action) {
>>     for(var element: elements) {
>>       action.accept(element);
>>     }
>>   }
>>   
>>   @Override
>>   public void replaceAll(UnaryOperator<E> operator) {
>>     for(var i = 0; i < elements.length; i++) {
>>       elements[i] = operator.apply(elements[i]);
>>     }
>>   }
>>   
>>   @Override
>>   public void sort(Comparator<? super E> comparator) {
>>     Arrays.sort(elements, comparator);
>>   }
>>   
>>   @Override
>>   public Spliterator<E> spliterator() {
>>     return Spliterators.spliterator(elements, Spliterator.ORDERED);
>>   }
>> }



From thartmann at openjdk.java.net  Thu May  7 06:46:07 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 7 May 2020 06:46:07 GMT
Subject: [lworld] FYI: 8244583: [lworld] TestIntrinsics fails due to
 unexpected getSuperclass() result
Message-ID: <yZvH_5jQVBHcD3cBPzZ0ssW9SL36lqlkRClatZ20Q0U=.d4e2b6d8-4369-402d-9743-9c7107e0c6f8@github.com>

Should test for MyValue1.ref.class instead of MyAbstract.class.

-------------

Commit messages:
 - Re-adding cast workaround
 - 8244583: [lworld] TestIntrinsics fails due to unexpected getSuperclass() result

Changes: https://git.openjdk.java.net/valhalla/pull/37/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/37/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244583
  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/37/head:pull/37

PR: https://git.openjdk.java.net/valhalla/pull/37


From thartmann at openjdk.java.net  Thu May  7 06:46:08 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 7 May 2020 06:46:08 GMT
Subject: [Integrated] [lworld] FYI: 8244583: [lworld] TestIntrinsics fails
 due to unexpected getSuperclass() result
In-Reply-To: <yZvH_5jQVBHcD3cBPzZ0ssW9SL36lqlkRClatZ20Q0U=.d4e2b6d8-4369-402d-9743-9c7107e0c6f8@github.com>
References: <yZvH_5jQVBHcD3cBPzZ0ssW9SL36lqlkRClatZ20Q0U=.d4e2b6d8-4369-402d-9743-9c7107e0c6f8@github.com>
Message-ID: <GyZeF65V4_4PzR_oDhfdLxFmdLtmIwq33K5vaJ-4XX0=.4d49d25d-1a12-4953-b8ee-8fe8ec0212ea@github.com>

On Thu, 7 May 2020 06:36:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Should test for MyValue1.ref.class instead of MyAbstract.class.

This pull request has now been integrated.

Changeset: 5c4f7299
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/5c4f7299
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8244583: [lworld] TestIntrinsics fails due to unexpected getSuperclass() result

-------------

PR: https://git.openjdk.java.net/valhalla/pull/37


From rwestrel at redhat.com  Thu May  7 07:34:29 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 07 May 2020 09:34:29 +0200
Subject: [lworld] RFR: 8244519: [lworld] C2 compilation fails with
 'monitors must always exist for synchronized methods'
In-Reply-To: <pC3KwzBpIJ0d7Ro6L59J-APUgsBGtVmBrY85LNkao8A=.830f25c1-968e-4003-af92-5a91a30603a9@github.com>
References: <pC3KwzBpIJ0d7Ro6L59J-APUgsBGtVmBrY85LNkao8A=.830f25c1-968e-4003-af92-5a91a30603a9@github.com>
Message-ID: <87h7ws5hbu.fsf@redhat.com>


>  Webrev: https://webrevs.openjdk.java.net/valhalla/36/webrev.00

Looks ok.

Roland.



From thartmann at openjdk.java.net  Thu May  7 08:05:19 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 7 May 2020 08:05:19 GMT
Subject: [lworld] RFR: 8244519: [lworld] C2 compilation fails with
 'monitors must always exist for synchronized methods'
In-Reply-To: <pC3KwzBpIJ0d7Ro6L59J-APUgsBGtVmBrY85LNkao8A=.830f25c1-968e-4003-af92-5a91a30603a9@github.com>
References: <pC3KwzBpIJ0d7Ro6L59J-APUgsBGtVmBrY85LNkao8A=.830f25c1-968e-4003-af92-5a91a30603a9@github.com>
Message-ID: <0V4qXW5w9ClKGoeIEjL0lQjDfrVaMQfFgjqPMlLihQI=.1ae31fa7-779a-44b0-99d6-cf5a11f9d463@github.com>

On Wed, 6 May 2020 16:09:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2 incorrectly assumes that the receiver of a synchronized method of an abstract class can be an inline type and
> therefore adds a runtime check to the locking code (see 'can_be_value_type' check in
> PhaseMacroExpand::expand_lock_node). While processing the JVMState of an uncommon trap emitted for that runtime check,
> we assert because there is no monitor (yet) although the method is synchronized.   I've modified
> ciInstanceKlass::can_be_value_klass accordingly and added an to catch similar problems earlier. I've also removed some
> dead code.  This fix includes the is_vanilla_constructor() fix from JDK-8243204.

Thanks Roland!

This pull request has now been integrated.

Changeset: 171da6aa
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/171da6aa
Stats:     45 lines in 4 files changed: 11 ins; 32 del; 2 mod

8244519: [lworld] C2 compilation fails with 'monitors must always exist for synchronized methods'

-------------

PR: https://git.openjdk.java.net/valhalla/pull/36


From dsimms at openjdk.java.net  Thu May  7 09:42:10 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 7 May 2020 09:42:10 GMT
Subject: [lworld] RFR: 8244584: Fix hotspot / runtime test compile errors
 after pivoting towards "lw3"
Message-ID: <xW_oi728JjxIGAuAMIoCBaGAhXFOabWIz1EOb7piEDQ=.728b3067-b658-4698-bd9e-a7bf5b85b50b@github.com>

Applied suggested fixes due to reference projection changes, cleaned out tabs from TestJNIArray

-------------

Commit messages:
 - 8244584: Fix hotspot / runtime test compile errors after pivoting towards "lw3"

Changes: https://git.openjdk.java.net/valhalla/pull/38/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/38/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244584
  Stats: 747 lines in 2 files changed: 7 ins; 6 del; 734 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/38/head:pull/38

PR: https://git.openjdk.java.net/valhalla/pull/38


From dsimms at openjdk.java.net  Thu May  7 09:46:33 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 7 May 2020 09:46:33 GMT
Subject: [Integrated] [lworld] RFR: 8244584: Fix hotspot / runtime test
 compile errors after pivoting towards "lw3"
In-Reply-To: <xW_oi728JjxIGAuAMIoCBaGAhXFOabWIz1EOb7piEDQ=.728b3067-b658-4698-bd9e-a7bf5b85b50b@github.com>
References: <xW_oi728JjxIGAuAMIoCBaGAhXFOabWIz1EOb7piEDQ=.728b3067-b658-4698-bd9e-a7bf5b85b50b@github.com>
Message-ID: <SC3XnzTN8Z1LPQSXlPZ2zRT08BeMjLlXT8n2bebZ098=.c13977c5-8239-46d3-bb0c-8d19e2576ab9@github.com>

On Thu, 7 May 2020 09:35:24 GMT, David Simms <dsimms at openjdk.org> wrote:

> Applied suggested fixes due to reference projection changes, cleaned out tabs from TestJNIArray

This pull request has now been integrated.

Changeset: b2f5a1a0
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b2f5a1a0
Stats:     742 lines in 2 files changed: 1 ins; 2 del; 739 mod

8244584: Fix hotspot / runtime test compile errors after pivoting towards "lw3"

-------------

PR: https://git.openjdk.java.net/valhalla/pull/38


From hseigel at openjdk.java.net  Thu May  7 15:29:45 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 7 May 2020 15:29:45 GMT
Subject: [lworld] [Rev 01] RFR: JDK-8243204 add class load time checking
 of abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
Message-ID: <pVcslY_iwKFQWtWVN9AA6U3gJsnX4R919FCM7tqTBzs=.f54b39fc-a9e4-4023-a14b-d3b874ab72a3@github.com>

> Please review this chagne.  It adds checks of super classes of inline classes.  It checks that an inline class's super
> class is  either java.lang.Object or an abstract class.  And, if abstract, checks that the super, and its super, etc.
> do not have instance fields, nor synchronized instance methods, or non-empty constructors, nor constructors with args.
> The fix was tested with tiers 1 - 3.

Harold Seigel has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains three commits:

 - Merge branch 'lworld' into abstractSuper
 - JDK-8243204 add class load time checking of abstract super classes of inline type
 - JDK-8243204 add class load time checking of abstract super classes of inline types

-------------

Changes: https://git.openjdk.java.net/valhalla/pull/34/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/34/webrev.01
  Stats: 2755 lines in 17 files changed: 2539 ins; 215 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/34.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/34/head:pull/34

PR: https://git.openjdk.java.net/valhalla/pull/34


From hseigel at openjdk.java.net  Thu May  7 15:39:22 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 7 May 2020 15:39:22 GMT
Subject: [lworld] RFR: JDK-8243204 add class load time checking of
 abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <jIv0zLfB8Tho-O3rzjqkD_3yMVVaOavxb4pfXBdr6BA=.b49d0c7f-084b-4c5a-a58c-5926fa3f1dfd@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
 <jIv0zLfB8Tho-O3rzjqkD_3yMVVaOavxb4pfXBdr6BA=.b49d0c7f-084b-4c5a-a58c-5926fa3f1dfd@github.com>
Message-ID: <ZYd-dAbivCcUtTfZwZPCC0L5crFbk9REDTA221oka3g=.cfc6d084-0e17-463f-af8f-9e7419d6786c@github.com>

On Mon, 4 May 2020 21:25:01 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this chagne.  It adds checks of super classes of inline classes.  It checks that an inline class's super
>> class is  either java.lang.Object or an abstract class.  And, if abstract, checks that the super, and its super, etc.
>> do not have instance fields, nor synchronized instance methods, or non-empty constructors, nor constructors with args.
>> The fix was tested with tiers 1 - 3.
>
> Shouldn't `ClassFileParser::check_super_of_inline_type()` also check that no super classes implement the
> `java.lang.IdentityObject` interface?

The update to the pull request implements John's "bit A and bit B" idea posted in the java-valhalla slack channel.
Instead of A and B, the flags are named invalid_inline_super and invalid_identity_super.  In this pull request,
invalid_identity_super exists but is never set nor read.  That is for a future change.

Flag invalid_inline_super is set to TRUE in a class's InstanceKlass, if, at class load time, the class is determined to
be an invalid super class for an inline type.

Checking that the class's constructor is abstract will be done at a future date once there is compiler support.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/34


From forax at univ-mlv.fr  Thu May  7 16:19:17 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 7 May 2020 18:19:17 +0200 (CEST)
Subject: Method reference doesn't work correctly
In-Reply-To: <d45a7016-b426-b3ac-c3ac-388c5e7abede@oracle.com>
References: <775158919.6247.1588803939278.JavaMail.zimbra@u-pem.fr>
 <d45a7016-b426-b3ac-c3ac-388c5e7abede@oracle.com>
Message-ID: <777469497.568340.1588868357466.JavaMail.zimbra@u-pem.fr>

[move to valhalla-dev]

----- Mail original -----
> De: "Srikanth" <srikanth.adayapalam at oracle.com>
> ?: "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Jeudi 7 Mai 2020 11:27:02
> Objet: Re: Method reference doesn't work correctly

> On 07/05/20 3:55 am, Remi Forax wrote:
>> Hi all,
>> the inference of method reference doesn't work properly
>>
>>    @__inline__ static class Foo {
>>      int x;
>>      Foo(int x) { this.x = x; }
>>    }
>>
>>    static void m(Foo foo) {
>>      System.out.println("inline");
>>    }
>>    static void m(Foo.ref foo) {
>>      System.out.println("ref");
>>    }
> 
> There is something wrong with the braces - these m() methods are not
> inside the class Foo,
> but the method reference below is to Foo::m


I was trying to create a reproducer for what you have called problem 3 in [1],
but i goof so no need to create a bug for this one.

> 
> Srikanth

R?mi

[1] https://github.com/openjdk/valhalla/pull/32

> 
>>    public static void main(String[] args) {
>>      var list = List.of(new Foo(3));
>>      list.forEach(e -> m(e));
>>      list.forEach(Foo::m);
>>    }
>>
>>
>> Hello.java:19: error: invalid method reference
>>      list.forEach(Foo::m);
>>                   ^
>>    cannot find symbol
>>      symbol:   method m(T)
>>      location: class Foo
>>    where T is a type-variable:
>>      T extends Object declared in interface Iterable
>>
>> regards,
> > R?mi


From forax at univ-mlv.fr  Thu May  7 16:45:15 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 7 May 2020 18:45:15 +0200 (CEST)
Subject: compiler issue with after the recent changes in the compiler
In-Reply-To: <6201899f-ab4e-de97-cc84-7436133afe0e@oracle.com>
References: <776674872.260.1588798161685.JavaMail.zimbra@u-pem.fr>
 <1413014100.1392.1588798594366.JavaMail.zimbra@u-pem.fr>
 <6201899f-ab4e-de97-cc84-7436133afe0e@oracle.com>
Message-ID: <715024951.581582.1588869915272.JavaMail.zimbra@u-pem.fr>

Thanks Srikanth,
i've used a version built this morning and now the diamond syntax works,
so most of my tests now works !

Despite the current issues with the compiler, I find the val/ref model far easier to use that the V? model,
the fact that something like List.of(inline) is inferred as List<Inline.ref> + the availability of all the members of an Inline on the its projection, Inline.ref helps a lot.

R?mi 

----- Mail original -----
> De: "Srikanth" <srikanth.adayapalam at oracle.com>
> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Jeudi 7 Mai 2020 01:45:36
> Objet: Re: compiler issue with after the recent changes in the compiler

> On 07/05/20 2:26 am, Remi Forax wrote:
>> Nope,
>> the bug is in wrap(), using E instead of the diamond and javac compiles
>>    public static <E> Array<E> wrap(E[] elements) {
>>      return new Array<>(Objects.requireNonNull(elements));   // crash
>>      return new Array<E>(Objects.requireNonNull(elements));  // compile
>>    }
> 
> Hello Remi,
> 
> Can you try again ? This was an acknowledged problem as of
> https://github.com/openjdk/valhalla/pull/32 which subsequently got
> resolved through https://bugs.openjdk.java.net/browse/JDK-8244458 (which
> itself got subsumed and cumulatively fixed via JDK-8244414)
> 
> I am able to compile the file Array.java you have attached without a
> crash. I'll add it to javac's tests anyways in a future commit.
> 
> Thanks!
> Srikanth
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Remi Forax" <forax at univ-mlv.fr>
>>> ?: "Srikanth Adayapalam" <sadayapalam at openjdk.java.net>
>>> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>>> Envoy?: Mercredi 6 Mai 2020 22:49:21
>>> Objet: compiler issue with after the recent changes in the compiler
>>> Hi Srikanth,
>>> using a version compiled yesterday, javac struggle with my code :)
>>> (i believe the issue is when compiling the method iterator() but i may be wrong)
>>>
>>> Also the "printing javac parameters" at the end looks like a debug knob not
>>> being turn off.
>>>
>>> regards,
>>> R?mi
>>>
>>> $ javac Array.java
>>> java.lang.NullPointerException
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.code.Types$13.visitClassType(Types.java:2331)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.code.Types$13.visitClassType(Types.java:2318)
>>> 	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1065)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4951)
>>> 	at jdk.compiler/com.sun.tools.javac.code.Types.memberType(Types.java:2315)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:589)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1597)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve.findDiamond(Resolve.java:2952)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve$13.doLookup(Resolve.java:2898)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:3367)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3617)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3602)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveDiamond(Resolve.java:2894)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2728)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1827)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitReturn(Attr.java:2316)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1684)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:781)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1456)
>>> 	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1044)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1239)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:890)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:689)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:763)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5308)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5190)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5112)
>>> 	at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:5057)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1348)
>>> 	at
>>> 	jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
>>> 	at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:316)
>>> 	at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>>> 	at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>>> 	at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>>> printing javac parameters to: /tmp/val-bug/javac.20200506_223738.args
>>>
>>>
>>> ---
>>>
>>> import static java.util.stream.IntStream.range;
>>>
>>> import java.util.Arrays;
>>> import java.util.Collection;
>>> import java.util.Comparator;
>>> import java.util.Iterator;
>>> import java.util.List;
>>> import java.util.ListIterator;
>>> import java.util.NoSuchElementException;
>>> import java.util.Objects;
>>> import java.util.Spliterator;
>>> import java.util.Spliterators;
>>> import java.util.function.Consumer;
>>> import java.util.function.Predicate;
>>> import java.util.function.UnaryOperator;
>>>
>>> @__inline__
>>> public final class Array<E> implements List<E> {
>>>   private final E[] elements;
>>>
>>>   private Array(E[] elements) {
>>>     this.elements = elements;
>>>   }
>>>
>>>   public static <E> Array<E> wrap(E[] elements) {
>>>     return new Array<>(Objects.requireNonNull(elements));
>>>   }
>>>
>>>   @SafeVarargs
>>>   public static <E> Array<E> of(E... elements) {
>>>     return wrap(elements);
>>>   }
>>>
>>>   public int length() {
>>>     return elements.length;
>>>   }
>>>   
>>>   @Override
>>>   public boolean equals(Object obj) {
>>>     if (obj instanceof Array) {
>>>       var array = (Array<?>)obj;
>>>       return Arrays.equals(elements, array.elements);
>>>     }
>>>     if (obj instanceof List) {
>>>       return equalsList((List<?>)obj);
>>>     }
>>>     return false;
>>>   }
>>>   private boolean equalsList(List<?> list) {
>>>     var it = list.iterator();
>>>     for(var element: elements) {
>>>       if (!it.hasNext()) {
>>>         return false;
>>>       }
>>>       var other = it.next();
>>>       if (!Objects.equals(element, other)) {
>>>         return false;
>>>       }
>>>     }
>>>     return !it.hasNext();
>>>   }
>>>   
>>>   @Override
>>>   public int hashCode() {
>>>     return Arrays.hashCode(elements);
>>>   }
>>>   
>>>   @Override
>>>   public String toString() {
>>>     return Arrays.toString(elements);
>>>   }
>>>
>>>   @Override
>>>   public int size() {
>>>     return elements.length;
>>>   }
>>>
>>>   @Override
>>>   public boolean isEmpty() {
>>>     return elements.length == 0;
>>>   }
>>>
>>>   @Override
>>>   public E get(int index) {
>>>     return elements[index];
>>>   }
>>>   
>>>   @Override
>>>   public E set(int index, E element) {
>>>     var old = elements[index];
>>>     elements[index] = element;
>>>     return old;
>>>   }
>>>   
>>>   @Override
>>>   public int indexOf(Object o) {
>>>     var length = elements.length;
>>>     return range(0, length).filter(i -> Objects.equals(o, elements[i])).findFirst()
>>>         .orElse(-1);
>>>   }
>>>   
>>>   @Override
>>>   public int lastIndexOf(Object o) {
>>>     for(var i = elements.length; --i >= 0;) {
>>>       if (Objects.equals(o, elements[i])) {
>>>         return i;
>>>       }
>>>     }
>>>     return -1;
>>>   }
>>>
>>>   @Override
>>>   public boolean contains(Object o) {
>>>     return Arrays.stream(elements).anyMatch(Predicate.isEqual(o));
>>>   }
>>>   
>>>   @Override
>>>   public boolean containsAll(Collection<?> collection) {
>>>     return collection.stream().allMatch(this::contains);
>>>   }
>>>
>>>   @Override
>>>   public Iterator<E> iterator() {
>>>     return new Iterator<>() {
>>>       private int index;
>>>       
>>>       @Override
>>>       public boolean hasNext() {
>>>         return index < elements.length;
>>>       }
>>>       @Override
>>>       public E next() {
>>>         if (!hasNext()) {
>>>           throw new NoSuchElementException("no such element");
>>>         }
>>>         return elements[index++];
>>>       }
>>>     };
>>>   }
>>>   
>>>   @Override
>>>   public ListIterator<E> listIterator() {
>>>     return listIterator(0);
>>>   }
>>>   @Override
>>>   public ListIterator<E> listIterator(int index) {
>>>     return Arrays.asList(elements).listIterator(index);
>>>   }
>>>   @Override
>>>   public List<E> subList(int fromIndex, int toIndex) {
>>>     return Arrays.asList(elements).subList(fromIndex, toIndex);
>>>   }
>>>   
>>>   @Override
>>>   public Object[] toArray() {
>>>     return Arrays.copyOf(elements, elements.length, Object[].class);
>>>   }
>>>
>>>   @Override
>>>   @SuppressWarnings("unchecked")
>>>   public <T> T[] toArray(T[] a) {
>>>     var elements = this.elements;
>>>     var length = elements.length;
>>>     if (a.length < length) {
>>>       return (T[])Arrays.copyOf(elements, length, a.getClass());
>>>     }
>>>     System.arraycopy(elements, 0, a, 0, length);
>>>     if (a.length > length) {
>>>       a[length] = null;
>>>     }
>>>     return a;
>>>   }
>>>
>>>   @Override
>>>   public boolean add(E e) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public void add(int index, E element) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public boolean addAll(Collection<? extends E> c) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public boolean addAll(int index, Collection<? extends E> c) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public void clear() {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public E remove(int index) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public boolean remove(Object o) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public boolean removeAll(Collection<?> c) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public boolean retainAll(Collection<?> c) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   @Override
>>>   public boolean removeIf(Predicate<? super E> filter) {
>>>     throw new UnsupportedOperationException("operation not supported");
>>>   }
>>>   
>>>   @Override
>>>   public void forEach(Consumer<? super E> action) {
>>>     for(var element: elements) {
>>>       action.accept(element);
>>>     }
>>>   }
>>>   
>>>   @Override
>>>   public void replaceAll(UnaryOperator<E> operator) {
>>>     for(var i = 0; i < elements.length; i++) {
>>>       elements[i] = operator.apply(elements[i]);
>>>     }
>>>   }
>>>   
>>>   @Override
>>>   public void sort(Comparator<? super E> comparator) {
>>>     Arrays.sort(elements, comparator);
>>>   }
>>>   
>>>   @Override
>>>   public Spliterator<E> spliterator() {
>>>     return Spliterators.spliterator(elements, Spliterator.ORDERED);
>>>   }
> >> }


From fparain at openjdk.java.net  Thu May  7 18:11:11 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 7 May 2020 18:11:11 GMT
Subject: [lworld] [Rev 01] RFR: JDK-8243204 add class load time checking
 of abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <pVcslY_iwKFQWtWVN9AA6U3gJsnX4R919FCM7tqTBzs=.f54b39fc-a9e4-4023-a14b-d3b874ab72a3@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
 <pVcslY_iwKFQWtWVN9AA6U3gJsnX4R919FCM7tqTBzs=.f54b39fc-a9e4-4023-a14b-d3b874ab72a3@github.com>
Message-ID: <mOGlXre_lumqL7Qoig34ADWl0PNos0FfyU-EQMBH_64=.be50fe5b-1b1a-4585-863b-93524b584527@github.com>

On Thu, 7 May 2020 15:29:45 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this chagne.  It adds checks of super classes of inline classes.  It checks that an inline class's super
>> class is  either java.lang.Object or an abstract class.  And, if abstract, checks that the super, and its super, etc.
>> do not have instance fields, nor synchronized instance methods, or non-empty constructors, nor constructors with args.
>> The fix was tested with tiers 1 - 3.
>
> Harold Seigel has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains three commits:
>  - Merge branch 'lworld' into abstractSuper
>  - JDK-8243204 add class load time checking of abstract super classes of inline type
>  - JDK-8243204 add class load time checking of abstract super classes of inline types

src/hotspot/share/oops/instanceKlass.hpp line 262:

> 261:   bool _invalid_inline_super;   // if true, invalid super type for an inline type.
> 262:   bool _invalid_identity_super; // if true, invalid super type for an identity type.
> 263:

Would it be possible to use two bits from `_misc_flags` instead of adding two bool fields to `InstanceKlass`?

src/hotspot/share/classfile/classFileParser.cpp line 6931:

> 6930:   return false;
> 6931: }
> 6932:

It seems this method could be made static.

src/hotspot/share/classfile/classFileParser.cpp line 6904:

> 6903: // does not implement interface java.lang.IdentityObject (checked elsewhere), has
> 6904: // an empty body-less no-arg constructor, and no synchronized instance methods.
> 6905: bool ClassFileParser::is_invalid_super_for_inline_type(const InstanceKlass* ik) {

The comment should be more explicit about the fact that it is performing a local test, without considering super types.
The final decision taking account super types being performed in `fill_instance_klass()`.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/34


From romanowski.mateusz at gmail.com  Thu May  7 21:57:02 2020
From: romanowski.mateusz at gmail.com (Mateusz Romanowski)
Date: Thu, 7 May 2020 21:57:02 +0000
Subject: Could the idea of null-default inline classes be revisited?
In-Reply-To: <F988CF72-3A07-48AC-9B14-62BDAC9E7325@oracle.com>
References: <CAL-BTSrACLfDkZohNsvHOw5imBXVktX70RTpcpvCfO2G4v6JPw@mail.gmail.com>
 <B54C05B2-2967-4B75-B339-54F92B4660A0@oracle.com>
 <F988CF72-3A07-48AC-9B14-62BDAC9E7325@oracle.com>
Message-ID: <CAL-BTSodv+f3QQjF3r+OE9iOmg+bHg25Xy9Vy+jnTOV51whNbQ@mail.gmail.com>

Hi John,
Thanks for the answer.

I have missed the idea of having both through manual transcoding in API
points. However, since accessibility of V.val and V.ref is same, I would
not export V and instead export another type sealed to permit just V.

Nonetheless, thanks for leaving the issue open to become a possible future
extension - I guess there are a few letters remaining to declare new
envelope if a disjoined namespace was needed.

Thanks,
Mateusz

On Wednesday, May 6, 2020, John Rose <john.r.rose at oracle.com> wrote:
> On May 6, 2020, at 12:46 PM, John Rose <john.r.rose at oracle.com> wrote:
>
> For now, the choice is pretty straightforward:  If you
> need null as a value in a variable of type V, use V.ref.
> If you need flatness in the variable, use V.val.  Choose
> one.
>
> P.S. If you need both, encapsulate the field as a V.val
> and transcode between V.default and (V.ref)null in
> access methods and constructors.  If you need naked
> fields *and* flatness *and* null, you are still out of luck.
> Sadly, record types won?t help with this, thought perhaps
> there?s some limited call for boxing/unboxing relations
> between a record?s internal and external field types;
> that?s another can of worms.  Use Java?s class-based
> data abstraction!


From john.r.rose at oracle.com  Fri May  8 00:41:03 2020
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 7 May 2020 17:41:03 -0700
Subject: Could the idea of null-default inline classes be revisited?
In-Reply-To: <CAL-BTSodv+f3QQjF3r+OE9iOmg+bHg25Xy9Vy+jnTOV51whNbQ@mail.gmail.com>
References: <CAL-BTSrACLfDkZohNsvHOw5imBXVktX70RTpcpvCfO2G4v6JPw@mail.gmail.com>
 <B54C05B2-2967-4B75-B339-54F92B4660A0@oracle.com>
 <F988CF72-3A07-48AC-9B14-62BDAC9E7325@oracle.com>
 <CAL-BTSodv+f3QQjF3r+OE9iOmg+bHg25Xy9Vy+jnTOV51whNbQ@mail.gmail.com>
Message-ID: <6862D55F-21B6-4043-B9CE-973E494D24F1@oracle.com>

On May 7, 2020, at 2:57 PM, Mateusz Romanowski <romanowski.mateusz at gmail.com> wrote:
> 
> accessibility of V.val and V.ref is same

That?s not necessarily true.  It?s possible, at least in the JVM,
for one type to be less public than the other.  They are necessarily
in the same package and module, but can independently be
package-private or public, to the JVM.  We are working out
language details on this, so stay tuned.  The idea of making
V.ref more public than V.val is related to the idea of giving
the ?good name? V to one or the other type; you might want
Optional to be public and mean Optional.ref, while Optional.val
is private, if for some reason you wanted to conceal the new
inline aspect.  (I don?t think we do in the case of Optional,
but you get the idea:  A type might be publicly ref-flavored,
with a hidden val aspect.  The other way around seems
less useful to me, but who knows.)

And still, a friendlier solution would be to allow both to be public
but ?hook? the conversion, relative to null, in the way we
discussed.  That?s a future discussion.

? John

From sadayapalam at openjdk.java.net  Fri May  8 01:54:53 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 8 May 2020 01:54:53 GMT
Subject: [lworld] RFR: 8244559: [lworld] Lambda and parameterized ref of an
 inline type doesn't work well
Message-ID: <fiHQAq0XBUphw9JwEMos765ScvRVVLvT2DEYnRwsU6I=.34cc2ab9-bfc1-48cf-a4d1-bca11d9ae063@github.com>

Jim, Could you please review this patch which fixes two problems? TIA.

(1) Basically, the code to create AST nodes from a Type is not handling reference
projection types properly. Given a type V.ref<T>, it ends up creating AST that
look like V<T>.ref rather than V.ref<T>

(2) When V<T> is a nested static class, the construct V.ref<T> _appears_ to
access a static member type of the parameterized type V which is usually an
error. But ref is not really a member and so this should be tolerated.

-------------

Commit messages:
 - 8244559: [lworld] Lambda and parameterized ref of an inline type doesn't work well

Changes: https://git.openjdk.java.net/valhalla/pull/39/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/39/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244559
  Stats: 73 lines in 3 files changed: 69 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/39.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/39/head:pull/39

PR: https://git.openjdk.java.net/valhalla/pull/39


From github.com+63007666+JimLaskey at openjdk.java.net  Fri May  8 12:32:01 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 8 May 2020 12:32:01 GMT
Subject: [lworld] RFR: 8244559: [lworld] Lambda and parameterized ref of
 an inline type doesn't work well
In-Reply-To: <fiHQAq0XBUphw9JwEMos765ScvRVVLvT2DEYnRwsU6I=.34cc2ab9-bfc1-48cf-a4d1-bca11d9ae063@github.com>
References: <fiHQAq0XBUphw9JwEMos765ScvRVVLvT2DEYnRwsU6I=.34cc2ab9-bfc1-48cf-a4d1-bca11d9ae063@github.com>
Message-ID: <-A8LxQMp14F9Gk5DmdPchP-OMH5TlH_SKjC0hB5rj4M=.6fa47c54-d643-4c5b-9d17-c5bc7307d0a0@github.com>

On Fri, 8 May 2020 01:48:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, Could you please review this patch which fixes two problems? TIA.
> 
> (1) Basically, the code to create AST nodes from a Type is not handling reference
> projection types properly. Given a type V.ref<T\>, it ends up creating AST that
> look like V<T\>.ref rather than V.ref<T\>
> 
> (2) When V<T\> is a nested static class, the construct V.ref<T\> _appears_ to
> access a static member type of the parameterized type V which is usually an
> error. But ref is not really a member and so this should be tolerated.

Marked as reviewed by JimLaskey at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/39


From sadayapalam at openjdk.java.net  Fri May  8 12:56:24 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 8 May 2020 12:56:24 GMT
Subject: [Integrated] [lworld] RFR: 8244559: [lworld] Lambda and
 parameterized ref of an inline type doesn't work well
In-Reply-To: <fiHQAq0XBUphw9JwEMos765ScvRVVLvT2DEYnRwsU6I=.34cc2ab9-bfc1-48cf-a4d1-bca11d9ae063@github.com>
References: <fiHQAq0XBUphw9JwEMos765ScvRVVLvT2DEYnRwsU6I=.34cc2ab9-bfc1-48cf-a4d1-bca11d9ae063@github.com>
Message-ID: <7fTgjDRenMkCCREHtcJvDRge8bMmzePgRxAR_4vhl18=.72b454e2-4211-4337-9610-cc16114cfe12@github.com>

On Fri, 8 May 2020 01:48:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, Could you please review this patch which fixes two problems? TIA.
> 
> (1) Basically, the code to create AST nodes from a Type is not handling reference
> projection types properly. Given a type V.ref<T\>, it ends up creating AST that
> look like V<T\>.ref rather than V.ref<T\>
> 
> (2) When V<T\> is a nested static class, the construct V.ref<T\> _appears_ to
> access a static member type of the parameterized type V which is usually an
> error. But ref is not really a member and so this should be tolerated.

This pull request has now been integrated.

Changeset: e586cdbe
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e586cdbe
Stats:     73 lines in 3 files changed: 0 ins; 69 del; 4 mod

8244559: [lworld] Lambda and parameterized ref of an inline type doesn't work well

-------------

PR: https://git.openjdk.java.net/valhalla/pull/39


From frederic.parain at oracle.com  Fri May  8 13:15:19 2020
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 8 May 2020 09:15:19 -0400
Subject: CONSTANT_Class_info and L-envelopes
Message-ID: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>

Greetings,

After the discussions of the past weeks about checkcast and the use of
envelopes in CONSTANT_Class_info entries, a consensus has been reached
for the case of Q-types. However, the case of L-types (should they use
an L-envelope or not) is still subject to discussion. In one hand,
forcing L-type to use envelopes would be a nice unifying move, in the
other hand, it would have a bigger impact on tools, requiring a flag
day approach instead of a smooth transition.

The current approach is to continue not to use L-envelopes in
CONSTANT_Class_info entries, but because some people might want to
experiment with L-envelopes, it has been suggested to add a VM flag
to support them.

Having a global flag to require that all class files use the same
format (either L-envelopes everywhere or L-envelopes nowhere) seems
impractical because it would require to recompile all classes to
switch from one mode to the other.

Being more lenient and supporting both modes causes a new issue:
the double syntax would allow a symbolic reference to a class to
exist in two forms inside a single class file: one form with the
L-envelope, one form without the L-envelope, creating two distinct
constant pool entries. The problem with having two entries representing
a symbolic reference to the same class is that there?s no guarantee
that the resolution of these two entries will produce the same result.

One solution to prevent this to happen would be to verify that a given
class is never referenced through two different entries, but this would
add a lot of checks during class file parsing.

Another solution would be to have a ?mode? per class file, either
always using L-envelopes, or never using them for CONSTANT_Class_info.
The class file doesn?t have to declare which mode it uses, this will
automatically detected by the JVM while processing the first
CONSTANT_Class_info entry, and then enforced for the remaining of the
processing of the class file. A global VM flag controls if the VM
must support the ?L-envelope required? mode or reject it (default
is to reject it).

This solution has been prototyped here:
http://cr.openjdk.java.net/~fparain/new_constant_class/webrev.00/index.html

It has been tested with manually modified class files, but has no unit
tests provided with the changeset.

Before submitting a pull-request, I?d like to have some feedback about this
approach. If you think this approach makes sense, I can push it, otherwise
I?ll drop it.

Thank you,

Fred



From brian.goetz at oracle.com  Fri May  8 14:44:29 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 8 May 2020 10:44:29 -0400
Subject: CONSTANT_Class_info and L-envelopes
In-Reply-To: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
References: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
Message-ID: <4519dbf1-e411-295f-a607-673ba9ae2b0c@oracle.com>

It is sad, but reasonable, that we can't remove this bit of spec tech 
debt all at once.

I would step back and say: what is the goal of having this flag?? Is it 
to experiment with tools ability to deal with a mixed world while we try 
and move towards a unified one?? If so, then your 
inferred-mode-per-classfile is good; it enforces that file writers do 
one or the other, while allowing different tools to migrate at their own 
rates.



On 5/8/2020 9:15 AM, Frederic Parain wrote:
> Greetings,
>
> After the discussions of the past weeks about checkcast and the use of
> envelopes in CONSTANT_Class_info entries, a consensus has been reached
> for the case of Q-types. However, the case of L-types (should they use
> an L-envelope or not) is still subject to discussion. In one hand,
> forcing L-type to use envelopes would be a nice unifying move, in the
> other hand, it would have a bigger impact on tools, requiring a flag
> day approach instead of a smooth transition.
>
> The current approach is to continue not to use L-envelopes in
> CONSTANT_Class_info entries, but because some people might want to
> experiment with L-envelopes, it has been suggested to add a VM flag
> to support them.
>
> Having a global flag to require that all class files use the same
> format (either L-envelopes everywhere or L-envelopes nowhere) seems
> impractical because it would require to recompile all classes to
> switch from one mode to the other.
>
> Being more lenient and supporting both modes causes a new issue:
> the double syntax would allow a symbolic reference to a class to
> exist in two forms inside a single class file: one form with the
> L-envelope, one form without the L-envelope, creating two distinct
> constant pool entries. The problem with having two entries representing
> a symbolic reference to the same class is that there?s no guarantee
> that the resolution of these two entries will produce the same result.
>
> One solution to prevent this to happen would be to verify that a given
> class is never referenced through two different entries, but this would
> add a lot of checks during class file parsing.
>
> Another solution would be to have a ?mode? per class file, either
> always using L-envelopes, or never using them for CONSTANT_Class_info.
> The class file doesn?t have to declare which mode it uses, this will
> automatically detected by the JVM while processing the first
> CONSTANT_Class_info entry, and then enforced for the remaining of the
> processing of the class file. A global VM flag controls if the VM
> must support the ?L-envelope required? mode or reject it (default
> is to reject it).
>
> This solution has been prototyped here:
> http://cr.openjdk.java.net/~fparain/new_constant_class/webrev.00/index.html
>
> It has been tested with manually modified class files, but has no unit
> tests provided with the changeset.
>
> Before submitting a pull-request, I?d like to have some feedback about this
> approach. If you think this approach makes sense, I can push it, otherwise
> I?ll drop it.
>
> Thank you,
>
> Fred
>



From frederic.parain at oracle.com  Fri May  8 14:50:06 2020
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 8 May 2020 10:50:06 -0400
Subject: CONSTANT_Class_info and L-envelopes
In-Reply-To: <4519dbf1-e411-295f-a607-673ba9ae2b0c@oracle.com>
References: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
 <4519dbf1-e411-295f-a607-673ba9ae2b0c@oracle.com>
Message-ID: <3FFEC36A-0BC6-444D-AAB7-16F485345A81@oracle.com>

The VM flag might be overkill, it?s mostly a remain of the version
where the policy was enforced globally. I can remove it.

Fred


> On May 8, 2020, at 10:44, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> It is sad, but reasonable, that we can't remove this bit of spec tech debt all at once.  
> 
> I would step back and say: what is the goal of having this flag?  Is it to experiment with tools ability to deal with a mixed world while we try and move towards a unified one?  If so, then your inferred-mode-per-classfile is good; it enforces that file writers do one or the other, while allowing different tools to migrate at their own rates.  
> 
> 
> 
> On 5/8/2020 9:15 AM, Frederic Parain wrote:
>> Greetings,
>> 
>> After the discussions of the past weeks about checkcast and the use of
>> envelopes in CONSTANT_Class_info entries, a consensus has been reached
>> for the case of Q-types. However, the case of L-types (should they use
>> an L-envelope or not) is still subject to discussion. In one hand,
>> forcing L-type to use envelopes would be a nice unifying move, in the
>> other hand, it would have a bigger impact on tools, requiring a flag
>> day approach instead of a smooth transition.
>> 
>> The current approach is to continue not to use L-envelopes in
>> CONSTANT_Class_info entries, but because some people might want to
>> experiment with L-envelopes, it has been suggested to add a VM flag
>> to support them.
>> 
>> Having a global flag to require that all class files use the same
>> format (either L-envelopes everywhere or L-envelopes nowhere) seems
>> impractical because it would require to recompile all classes to
>> switch from one mode to the other.
>> 
>> Being more lenient and supporting both modes causes a new issue:
>> the double syntax would allow a symbolic reference to a class to
>> exist in two forms inside a single class file: one form with the
>> L-envelope, one form without the L-envelope, creating two distinct
>> constant pool entries. The problem with having two entries representing
>> a symbolic reference to the same class is that there?s no guarantee
>> that the resolution of these two entries will produce the same result.
>> 
>> One solution to prevent this to happen would be to verify that a given
>> class is never referenced through two different entries, but this would
>> add a lot of checks during class file parsing.
>> 
>> Another solution would be to have a ?mode? per class file, either
>> always using L-envelopes, or never using them for CONSTANT_Class_info.
>> The class file doesn?t have to declare which mode it uses, this will
>> automatically detected by the JVM while processing the first
>> CONSTANT_Class_info entry, and then enforced for the remaining of the
>> processing of the class file. A global VM flag controls if the VM
>> must support the ?L-envelope required? mode or reject it (default
>> is to reject it).
>> 
>> This solution has been prototyped here:
>> 
>> http://cr.openjdk.java.net/~fparain/new_constant_class/webrev.00/index.html
>> 
>> 
>> It has been tested with manually modified class files, but has no unit
>> tests provided with the changeset.
>> 
>> Before submitting a pull-request, I?d like to have some feedback about this
>> approach. If you think this approach makes sense, I can push it, otherwise
>> I?ll drop it.
>> 
>> Thank you,
>> 
>> Fred
>> 
>> 
> 



From hseigel at openjdk.java.net  Fri May  8 15:02:07 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 8 May 2020 15:02:07 GMT
Subject: [lworld] [Rev 02] RFR: JDK-8243204 add class load time checking
 of abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
Message-ID: <eBm8oDFoaWxKtWMFY6iQaYoUCAkRSdzeCkWPTsxamVA=.280c15b4-0b8f-4804-a1e6-e4dd494385ff@github.com>

> Please review this chagne.  It adds checks of super classes of inline classes.  It checks that an inline class's super
> class is  either java.lang.Object or an abstract class.  And, if abstract, checks that the super, and its super, etc.
> do not have instance fields, nor synchronized instance methods, or non-empty constructors, nor constructors with args.
> The fix was tested with tiers 1 - 3.

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8243204 [lworld] add checking of abstract super classes of inline type 3

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/34/files
  - new: https://git.openjdk.java.net/valhalla/pull/34/files/b00ed2a7..9ff28565

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/34/webrev.02
 - incr: https://webrevs.openjdk.java.net/valhalla/34/webrev.01-02

  Stats: 114 lines in 4 files changed: 57 ins; 53 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/34.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/34/head:pull/34

PR: https://git.openjdk.java.net/valhalla/pull/34


From hseigel at openjdk.java.net  Fri May  8 15:04:43 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 8 May 2020 15:04:43 GMT
Subject: [lworld] RFR: JDK-8243204 add class load time checking of
 abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <ZYd-dAbivCcUtTfZwZPCC0L5crFbk9REDTA221oka3g=.cfc6d084-0e17-463f-af8f-9e7419d6786c@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
 <jIv0zLfB8Tho-O3rzjqkD_3yMVVaOavxb4pfXBdr6BA=.b49d0c7f-084b-4c5a-a58c-5926fa3f1dfd@github.com>
 <ZYd-dAbivCcUtTfZwZPCC0L5crFbk9REDTA221oka3g=.cfc6d084-0e17-463f-af8f-9e7419d6786c@github.com>
Message-ID: <1ATJbuSaJsPE9e0BsBmy36glkSyAgSB54p5cqo3hB7U=.30dacaa6-de57-4dff-815f-d186767698e8@github.com>

On Thu, 7 May 2020 15:36:58 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Shouldn't `ClassFileParser::check_super_of_inline_type()` also check that no super classes implement the
>> `java.lang.IdentityObject` interface?
>
> The update to the pull request implements John's "bit A and bit B" idea posted in the java-valhalla slack channel.
> Instead of A and B, the flags are named invalid_inline_super and invalid_identity_super.  In this pull request,
> invalid_identity_super exists but is never set nor read.  That is for a future change.  Flag invalid_inline_super is
> set to TRUE in a class's InstanceKlass, if, at class load time, the class is determined to be an invalid super class
> for an inline type.  Checking that the class's constructor is abstract will be done at a future date once there is
> compiler support.

Today's updated change improves the comment for function is_invalid_super_for_inline_type() and makes it a static
function.  Also, it moves the InstanceKlass invalid_inline_super and invalid_identity_super flags into misc_flags.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/34


From forax at univ-mlv.fr  Fri May  8 15:06:48 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 8 May 2020 17:06:48 +0200 (CEST)
Subject: Lambda and parameterized ref of an inline type doesn't work well
In-Reply-To: <fb477772-98fb-6a23-5b82-18d1ccea5a73@oracle.com>
References: <1782085040.6556.1588804634413.JavaMail.zimbra@u-pem.fr>
 <fb477772-98fb-6a23-5b82-18d1ccea5a73@oracle.com>
Message-ID: <1940132243.851285.1588950408593.JavaMail.zimbra@u-pem.fr>

[move to valhalla-dev]

Hi Srikanth,
This seems to fix the lambda bug but not the one with the enhanced for loop.
Here, the inline type is itself a generics so it should work as usual.

  @__inline__ static class Foo<V> implements Iterable<V> {
    int x = 3;
    
    public Iterator<V> iterator() {
      return null;
    }
  }


  public static void main(String[] args) {
    Foo<String> foo = new Foo<String>();
    for(var s: foo) {
    }
  }


$javac Hello.java 
Hello.java:15: error: for-each not applicable to expression type
    for(var s: foo) {
               ^
  required: array or java.lang.Iterable
  found:    Foo<String>
1 error

regards,
R?mi

----- Mail original -----
> De: "Srikanth" <srikanth.adayapalam at oracle.com>
> ?: "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Vendredi 8 Mai 2020 15:00:46
> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well

> Hello Remi,
> 
> Thanks for the report - this should be fixed by the commit
> https://github.com/openjdk/valhalla/commit/e586cdbe made for
> https://bugs.openjdk.java.net/browse/JDK-8244559
> 
> With this all three problems reported are solved and should work now.
> 
> (The inline + record synthesized methods is open)
> 
> Srikanth
> 
> On 07/05/20 4:07 am, Remi Forax wrote:
>>    @__inline__ static class Foo<V> {
>>      int x;
>>      Foo(int x) { this.x = x; }
>>    }
>>
>>    static void m(Foo foo) {
>>      System.out.println("inline");
>>    }
>>    static void m(Foo.ref foo) {
>>      System.out.println("ref");
>>    }
>>
>>    public static void main(String[] args) {
>>      List<Foo.ref<Integer>> list = List.of(new Foo<Integer>(3));
>>      list.stream().forEach(e -> m(e));
>>    }
>>
>> I don't even understand the error message when playing with parameterized ref of
>> an inline type.
>>
>> error: cannot select a static class from a parameterized type
>> Hello.java:19: error: incompatible types: incompatible parameter types in lambda
>> expression
>>      list.stream().forEach(e -> m(e));
>>                            ^
>>
>> regards,
> > R?mi


From hseigel at openjdk.java.net  Fri May  8 15:04:49 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 8 May 2020 15:04:49 GMT
Subject: [lworld] [Rev 01] RFR: JDK-8243204 add class load time checking
 of abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <mOGlXre_lumqL7Qoig34ADWl0PNos0FfyU-EQMBH_64=.be50fe5b-1b1a-4585-863b-93524b584527@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
 <pVcslY_iwKFQWtWVN9AA6U3gJsnX4R919FCM7tqTBzs=.f54b39fc-a9e4-4023-a14b-d3b874ab72a3@github.com>
 <mOGlXre_lumqL7Qoig34ADWl0PNos0FfyU-EQMBH_64=.be50fe5b-1b1a-4585-863b-93524b584527@github.com>
Message-ID: <Z2sKdQ_047yvQfdlO1PPCZYLF2Q8X9dY7dHOiUUxP4U=.2d31f271-fe6f-4068-98e7-f2e173791717@github.com>

On Thu, 7 May 2020 18:08:31 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Harold Seigel has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains three commits:
>>  - Merge branch 'lworld' into abstractSuper
>>  - JDK-8243204 add class load time checking of abstract super classes of inline type
>>  - JDK-8243204 add class load time checking of abstract super classes of inline types
>
> src/hotspot/share/classfile/classFileParser.cpp line 6904:
> 
>> 6903: // does not implement interface java.lang.IdentityObject (checked elsewhere), has
>> 6904: // an empty body-less no-arg constructor, and no synchronized instance methods.
>> 6905: bool ClassFileParser::is_invalid_super_for_inline_type(const InstanceKlass* ik) {
> 
> The comment should be more explicit about the fact that it is performing a local test, without considering super types.
> The final decision taking account super types being performed in `fill_instance_klass()`.

The latest change updates this comment.

> src/hotspot/share/classfile/classFileParser.cpp line 6931:
> 
>> 6930:   return false;
>> 6931: }
>> 6932:
> 
> It seems this method could be made static.

Done.

> src/hotspot/share/oops/instanceKlass.hpp line 262:
> 
>> 261:   bool _invalid_inline_super;   // if true, invalid super type for an inline type.
>> 262:   bool _invalid_identity_super; // if true, invalid super type for an identity type.
>> 263:
> 
> Would it be possible to use two bits from `_misc_flags` instead of adding two bool fields to `InstanceKlass`?

Done.  Thanks for the suggestion!

-------------

PR: https://git.openjdk.java.net/valhalla/pull/34


From fparain at openjdk.java.net  Fri May  8 15:12:06 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 8 May 2020 15:12:06 GMT
Subject: [lworld] [Rev 02] RFR: JDK-8243204 add class load time checking
 of abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <eBm8oDFoaWxKtWMFY6iQaYoUCAkRSdzeCkWPTsxamVA=.280c15b4-0b8f-4804-a1e6-e4dd494385ff@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
 <eBm8oDFoaWxKtWMFY6iQaYoUCAkRSdzeCkWPTsxamVA=.280c15b4-0b8f-4804-a1e6-e4dd494385ff@github.com>
Message-ID: <41-DFjHMtlC7_8zDkI843ooHRcZOYgIUNTo9K81AilM=.080e8c70-8158-45a5-b0e9-d1f60db05879@github.com>

On Fri, 8 May 2020 15:02:07 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this chagne.  It adds checks of super classes of inline classes.  It checks that an inline class's super
>> class is  either java.lang.Object or an abstract class.  And, if abstract, checks that the super, and its super, etc.
>> do not have instance fields, nor synchronized instance methods, or non-empty constructors, nor constructors with args.
>> The fix was tested with tiers 1 - 3.
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8243204 [lworld] add checking of abstract super classes of inline type 3

Thank you for the changes.
Looks good to me.

Fred

-------------

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/34


From forax at univ-mlv.fr  Fri May  8 15:19:43 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 8 May 2020 17:19:43 +0200 (CEST)
Subject: CONSTANT_Class_info and L-envelopes
In-Reply-To: <3FFEC36A-0BC6-444D-AAB7-16F485345A81@oracle.com>
References: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
 <4519dbf1-e411-295f-a607-673ba9ae2b0c@oracle.com>
 <3FFEC36A-0BC6-444D-AAB7-16F485345A81@oracle.com>
Message-ID: <960519336.853525.1588951183741.JavaMail.zimbra@u-pem.fr>

Another solution is to use the preview feature mode instead of a flag,
i.e. only allow L-envelope mode for constant class info if the minor version is all 1s.

R?mi

----- Mail original -----
> De: "Frederic Parain" <frederic.parain at oracle.com>
> ?: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Vendredi 8 Mai 2020 16:50:06
> Objet: Re: CONSTANT_Class_info and L-envelopes

> The VM flag might be overkill, it?s mostly a remain of the version
> where the policy was enforced globally. I can remove it.
> 
> Fred
> 
> 
>> On May 8, 2020, at 10:44, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> It is sad, but reasonable, that we can't remove this bit of spec tech debt all
>> at once.
>> 
>> I would step back and say: what is the goal of having this flag?  Is it to
>> experiment with tools ability to deal with a mixed world while we try and move
>> towards a unified one?  If so, then your inferred-mode-per-classfile is good;
>> it enforces that file writers do one or the other, while allowing different
>> tools to migrate at their own rates.
>> 
>> 
>> 
>> On 5/8/2020 9:15 AM, Frederic Parain wrote:
>>> Greetings,
>>> 
>>> After the discussions of the past weeks about checkcast and the use of
>>> envelopes in CONSTANT_Class_info entries, a consensus has been reached
>>> for the case of Q-types. However, the case of L-types (should they use
>>> an L-envelope or not) is still subject to discussion. In one hand,
>>> forcing L-type to use envelopes would be a nice unifying move, in the
>>> other hand, it would have a bigger impact on tools, requiring a flag
>>> day approach instead of a smooth transition.
>>> 
>>> The current approach is to continue not to use L-envelopes in
>>> CONSTANT_Class_info entries, but because some people might want to
>>> experiment with L-envelopes, it has been suggested to add a VM flag
>>> to support them.
>>> 
>>> Having a global flag to require that all class files use the same
>>> format (either L-envelopes everywhere or L-envelopes nowhere) seems
>>> impractical because it would require to recompile all classes to
>>> switch from one mode to the other.
>>> 
>>> Being more lenient and supporting both modes causes a new issue:
>>> the double syntax would allow a symbolic reference to a class to
>>> exist in two forms inside a single class file: one form with the
>>> L-envelope, one form without the L-envelope, creating two distinct
>>> constant pool entries. The problem with having two entries representing
>>> a symbolic reference to the same class is that there?s no guarantee
>>> that the resolution of these two entries will produce the same result.
>>> 
>>> One solution to prevent this to happen would be to verify that a given
>>> class is never referenced through two different entries, but this would
>>> add a lot of checks during class file parsing.
>>> 
>>> Another solution would be to have a ?mode? per class file, either
>>> always using L-envelopes, or never using them for CONSTANT_Class_info.
>>> The class file doesn?t have to declare which mode it uses, this will
>>> automatically detected by the JVM while processing the first
>>> CONSTANT_Class_info entry, and then enforced for the remaining of the
>>> processing of the class file. A global VM flag controls if the VM
>>> must support the ?L-envelope required? mode or reject it (default
>>> is to reject it).
>>> 
>>> This solution has been prototyped here:
>>> 
>>> http://cr.openjdk.java.net/~fparain/new_constant_class/webrev.00/index.html
>>> 
>>> 
>>> It has been tested with manually modified class files, but has no unit
>>> tests provided with the changeset.
>>> 
>>> Before submitting a pull-request, I?d like to have some feedback about this
>>> approach. If you think this approach makes sense, I can push it, otherwise
>>> I?ll drop it.
>>> 
>>> Thank you,
>>> 
>>> Fred
>>> 
>>> 


From frederic.parain at oracle.com  Fri May  8 15:19:40 2020
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 8 May 2020 11:19:40 -0400
Subject: CONSTANT_Class_info and L-envelopes
In-Reply-To: <3FFEC36A-0BC6-444D-AAB7-16F485345A81@oracle.com>
References: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
 <4519dbf1-e411-295f-a607-673ba9ae2b0c@oracle.com>
 <3FFEC36A-0BC6-444D-AAB7-16F485345A81@oracle.com>
Message-ID: <6707E07F-5D24-4B58-ADE0-378E231C0F6E@oracle.com>

New webrev:

http://cr.openjdk.java.net/~fparain/new_constant_class/webrev.01/index.html

Fred

> On May 8, 2020, at 10:50, Frederic Parain <frederic.parain at oracle.com> wrote:
> 
> The VM flag might be overkill, it?s mostly a remain of the version
> where the policy was enforced globally. I can remove it.
> 
> Fred
> 
> 
>> On May 8, 2020, at 10:44, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> It is sad, but reasonable, that we can't remove this bit of spec tech debt all at once.  
>> 
>> I would step back and say: what is the goal of having this flag?  Is it to experiment with tools ability to deal with a mixed world while we try and move towards a unified one?  If so, then your inferred-mode-per-classfile is good; it enforces that file writers do one or the other, while allowing different tools to migrate at their own rates.  
>> 
>> 
>> 
>> On 5/8/2020 9:15 AM, Frederic Parain wrote:
>>> Greetings,
>>> 
>>> After the discussions of the past weeks about checkcast and the use of
>>> envelopes in CONSTANT_Class_info entries, a consensus has been reached
>>> for the case of Q-types. However, the case of L-types (should they use
>>> an L-envelope or not) is still subject to discussion. In one hand,
>>> forcing L-type to use envelopes would be a nice unifying move, in the
>>> other hand, it would have a bigger impact on tools, requiring a flag
>>> day approach instead of a smooth transition.
>>> 
>>> The current approach is to continue not to use L-envelopes in
>>> CONSTANT_Class_info entries, but because some people might want to
>>> experiment with L-envelopes, it has been suggested to add a VM flag
>>> to support them.
>>> 
>>> Having a global flag to require that all class files use the same
>>> format (either L-envelopes everywhere or L-envelopes nowhere) seems
>>> impractical because it would require to recompile all classes to
>>> switch from one mode to the other.
>>> 
>>> Being more lenient and supporting both modes causes a new issue:
>>> the double syntax would allow a symbolic reference to a class to
>>> exist in two forms inside a single class file: one form with the
>>> L-envelope, one form without the L-envelope, creating two distinct
>>> constant pool entries. The problem with having two entries representing
>>> a symbolic reference to the same class is that there?s no guarantee
>>> that the resolution of these two entries will produce the same result.
>>> 
>>> One solution to prevent this to happen would be to verify that a given
>>> class is never referenced through two different entries, but this would
>>> add a lot of checks during class file parsing.
>>> 
>>> Another solution would be to have a ?mode? per class file, either
>>> always using L-envelopes, or never using them for CONSTANT_Class_info.
>>> The class file doesn?t have to declare which mode it uses, this will
>>> automatically detected by the JVM while processing the first
>>> CONSTANT_Class_info entry, and then enforced for the remaining of the
>>> processing of the class file. A global VM flag controls if the VM
>>> must support the ?L-envelope required? mode or reject it (default
>>> is to reject it).
>>> 
>>> This solution has been prototyped here:
>>> 
>>> http://cr.openjdk.java.net/~fparain/new_constant_class/webrev.00/index.html
>>> 
>>> 
>>> It has been tested with manually modified class files, but has no unit
>>> tests provided with the changeset.
>>> 
>>> Before submitting a pull-request, I?d like to have some feedback about this
>>> approach. If you think this approach makes sense, I can push it, otherwise
>>> I?ll drop it.
>>> 
>>> Thank you,
>>> 
>>> Fred
>>> 
>>> 
>> 
> 



From hseigel at openjdk.java.net  Fri May  8 15:28:47 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 8 May 2020 15:28:47 GMT
Subject: [Integrated] [lworld] RFR: JDK-8243204 add class load time
 checking of abstract super classes =?UTF-8?B?b2bigKY=?=
In-Reply-To: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
References: <-yxpdSnxAkikhZpd6wuSMpU-HghJS_3OLoU3-jfcRbQ=.5a090830-41c1-4969-8580-7b2952faf90f@github.com>
Message-ID: <2g8j_yYL0LdVfxy6TMQ1nl1vWTFFJ_-bAZEZ5dqwM-Y=.f75ce0f3-2dc9-42f3-99a7-73dcbb2fc151@github.com>

On Mon, 4 May 2020 20:04:38 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this chagne.  It adds checks of super classes of inline classes.  It checks that an inline class's super
> class is  either java.lang.Object or an abstract class.  And, if abstract, checks that the super, and its super, etc.
> do not have instance fields, nor synchronized instance methods, or non-empty constructors, nor constructors with args.
> The fix was tested with tiers 1 - 3.

This pull request has now been integrated.

Changeset: b00578fa
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b00578fa
Stats:     2755 lines in 17 files changed: 210 ins; 2538 del; 7 mod

JDK-8243204 add class load time checking of abstract super classes of?

Reviewed-by: fparain

-------------

PR: https://git.openjdk.java.net/valhalla/pull/34


From romanowski.mateusz at gmail.com  Fri May  8 22:00:23 2020
From: romanowski.mateusz at gmail.com (Mateusz Romanowski)
Date: Fri, 8 May 2020 22:00:23 +0000
Subject: Could the idea of null-default inline classes be revisited?
In-Reply-To: <6862D55F-21B6-4043-B9CE-973E494D24F1@oracle.com>
References: <CAL-BTSrACLfDkZohNsvHOw5imBXVktX70RTpcpvCfO2G4v6JPw@mail.gmail.com>
 <B54C05B2-2967-4B75-B339-54F92B4660A0@oracle.com>
 <F988CF72-3A07-48AC-9B14-62BDAC9E7325@oracle.com>
 <CAL-BTSodv+f3QQjF3r+OE9iOmg+bHg25Xy9Vy+jnTOV51whNbQ@mail.gmail.com>
 <6862D55F-21B6-4043-B9CE-973E494D24F1@oracle.com>
Message-ID: <CAL-BTSqSk12+c3CwTOyx79=W3A5kJvtqoxu8wRQjs3VN2QKyQA@mail.gmail.com>

Sounds cool - can't wait on learning Java syntax.

I'll stay tuned for other developments.

/Mateusz

On Friday, May 8, 2020, John Rose <john.r.rose at oracle.com> wrote:
> On May 7, 2020, at 2:57 PM, Mateusz Romanowski <
romanowski.mateusz at gmail.com> wrote:
>
> accessibility of V.val and V.ref is same
>
> That?s not necessarily true.  It?s possible, at least in the JVM,
> for one type to be less public than the other.  They are necessarily
> in the same package and module, but can independently be
> package-private or public, to the JVM.  We are working out
> language details on this, so stay tuned.  The idea of making
> V.ref more public than V.val is related to the idea of giving
> the ?good name? V to one or the other type; you might want
> Optional to be public and mean Optional.ref, while Optional.val
> is private, if for some reason you wanted to conceal the new
> inline aspect.  (I don?t think we do in the case of Optional,
> but you get the idea:  A type might be publicly ref-flavored,
> with a hidden val aspect.  The other way around seems
> less useful to me, but who knows.)
> And still, a friendlier solution would be to allow both to be public
> but ?hook? the conversion, relative to null, in the way we
> discussed.  That?s a future discussion.
> ? John


From forax at univ-mlv.fr  Fri May  8 22:55:55 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 9 May 2020 00:55:55 +0200 (CEST)
Subject: System.identityHashCode
Message-ID: <352804674.930089.1588978555643.JavaMail.zimbra@u-pem.fr>

Hi all,
it seems to me that for the current implementation the value returned by identityHashCode doesn't depend on the field values on the inlining classes but only the class.

What is the rational for such choice (if i'm right) ?

regards,
R?mi


From john.r.rose at oracle.com  Fri May  8 23:31:51 2020
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 8 May 2020 16:31:51 -0700
Subject: System.identityHashCode
In-Reply-To: <352804674.930089.1588978555643.JavaMail.zimbra@u-pem.fr>
References: <352804674.930089.1588978555643.JavaMail.zimbra@u-pem.fr>
Message-ID: <A044A27C-2ED2-4312-A45B-C6AF4D7A6798@oracle.com>

That?s a lame but correct implementation.  Making it higher quality will require some effort. An ideal implementation would make every bit of the output depend on every bit of the input that could affect the outcome of the acmp bytecode. And it would be fast. Therefore we have trade-offs to make.

> On May 8, 2020, at 3:56 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ?Hi all,
> it seems to me that for the current implementation the value returned by identityHashCode doesn't depend on the field values on the inlining classes but only the class.
> 
> What is the rational for such choice (if i'm right) ?
> 
> regards,
> R?mi



From srikanth.adayapalam at oracle.com  Sat May  9 00:52:26 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Sat, 9 May 2020 06:22:26 +0530
Subject: Lambda and parameterized ref of an inline type doesn't work well
In-Reply-To: <1940132243.851285.1588950408593.JavaMail.zimbra@u-pem.fr>
References: <1782085040.6556.1588804634413.JavaMail.zimbra@u-pem.fr>
 <fb477772-98fb-6a23-5b82-18d1ccea5a73@oracle.com>
 <1940132243.851285.1588950408593.JavaMail.zimbra@u-pem.fr>
Message-ID: <56a7a881-36c9-b586-25ec-0deecbca5e13@oracle.com>



On 08/05/20 8:36 pm, Remi Forax wrote:
> [move to valhalla-dev]
>
> Hi Srikanth,
> This seems to fix the lambda bug but not the one with the enhanced for loop.

"not the one with enhanced for loop" - I'll take a look, but was this 
reported earlier ?
Your wording seems to indicate so, but I seem to have missed the report 
and am
hearing it only now.

In any case, I expect to have a fix soon. Thanks so much for testing and 
the defect
reports!

Srikanth

> Here, the inline type is itself a generics so it should work as usual.
>
>    @__inline__ static class Foo<V> implements Iterable<V> {
>      int x = 3;
>      
>      public Iterator<V> iterator() {
>        return null;
>      }
>    }
>
>
>    public static void main(String[] args) {
>      Foo<String> foo = new Foo<String>();
>      for(var s: foo) {
>      }
>    }
>
>
> $javac Hello.java
> Hello.java:15: error: for-each not applicable to expression type
>      for(var s: foo) {
>                 ^
>    required: array or java.lang.Iterable
>    found:    Foo<String>
> 1 error
>
> regards,
> R?mi
>
> ----- Mail original -----
>> De: "Srikanth" <srikanth.adayapalam at oracle.com>
>> ?: "amber-dev" <amber-dev at openjdk.java.net>
>> Envoy?: Vendredi 8 Mai 2020 15:00:46
>> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well
>> Hello Remi,
>>
>> Thanks for the report - this should be fixed by the commit
>> https://github.com/openjdk/valhalla/commit/e586cdbe made for
>> https://bugs.openjdk.java.net/browse/JDK-8244559
>>
>> With this all three problems reported are solved and should work now.
>>
>> (The inline + record synthesized methods is open)
>>
>> Srikanth
>>
>> On 07/05/20 4:07 am, Remi Forax wrote:
>>>     @__inline__ static class Foo<V> {
>>>       int x;
>>>       Foo(int x) { this.x = x; }
>>>     }
>>>
>>>     static void m(Foo foo) {
>>>       System.out.println("inline");
>>>     }
>>>     static void m(Foo.ref foo) {
>>>       System.out.println("ref");
>>>     }
>>>
>>>     public static void main(String[] args) {
>>>       List<Foo.ref<Integer>> list = List.of(new Foo<Integer>(3));
>>>       list.stream().forEach(e -> m(e));
>>>     }
>>>
>>> I don't even understand the error message when playing with parameterized ref of
>>> an inline type.
>>>
>>> error: cannot select a static class from a parameterized type
>>> Hello.java:19: error: incompatible types: incompatible parameter types in lambda
>>> expression
>>>       list.stream().forEach(e -> m(e));
>>>                             ^
>>>
>>> regards,
>>> R?mi



From forax at univ-mlv.fr  Sat May  9 11:33:25 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 9 May 2020 13:33:25 +0200 (CEST)
Subject: Lambda and parameterized ref of an inline type doesn't work well
In-Reply-To: <56a7a881-36c9-b586-25ec-0deecbca5e13@oracle.com>
References: <1782085040.6556.1588804634413.JavaMail.zimbra@u-pem.fr>
 <fb477772-98fb-6a23-5b82-18d1ccea5a73@oracle.com>
 <1940132243.851285.1588950408593.JavaMail.zimbra@u-pem.fr>
 <56a7a881-36c9-b586-25ec-0deecbca5e13@oracle.com>
Message-ID: <136811189.1028494.1589024005845.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Srikanth" <srikanth.adayapalam at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Samedi 9 Mai 2020 02:52:26
> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well

> On 08/05/20 8:36 pm, Remi Forax wrote:
>> [move to valhalla-dev]
>>
>> Hi Srikanth,
>> This seems to fix the lambda bug but not the one with the enhanced for loop.
> 
> "not the one with enhanced for loop" - I'll take a look, but was this
> reported earlier ?
> Your wording seems to indicate so, but I seem to have missed the report
> and am hearing it only now.

I've mention it in the comment section of JDK-8244559, for me it comes from the same piece code but it's maybe another error.

> 
> In any case, I expect to have a fix soon. Thanks so much for testing and
> the defect reports!

No, thank you for your impressive work.

> 
> Srikanth

R?mi

[1] https://bugs.openjdk.java.net/browse/JDK-8244559

> 
>> Here, the inline type is itself a generics so it should work as usual.
>>
>>    @__inline__ static class Foo<V> implements Iterable<V> {
>>      int x = 3;
>>      
>>      public Iterator<V> iterator() {
>>        return null;
>>      }
>>    }
>>
>>
>>    public static void main(String[] args) {
>>      Foo<String> foo = new Foo<String>();
>>      for(var s: foo) {
>>      }
>>    }
>>
>>
>> $javac Hello.java
>> Hello.java:15: error: for-each not applicable to expression type
>>      for(var s: foo) {
>>                 ^
>>    required: array or java.lang.Iterable
>>    found:    Foo<String>
>> 1 error
>>
>> regards,
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Srikanth" <srikanth.adayapalam at oracle.com>
>>> ?: "amber-dev" <amber-dev at openjdk.java.net>
>>> Envoy?: Vendredi 8 Mai 2020 15:00:46
>>> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well
>>> Hello Remi,
>>>
>>> Thanks for the report - this should be fixed by the commit
>>> https://github.com/openjdk/valhalla/commit/e586cdbe made for
>>> https://bugs.openjdk.java.net/browse/JDK-8244559
>>>
>>> With this all three problems reported are solved and should work now.
>>>
>>> (The inline + record synthesized methods is open)
>>>
>>> Srikanth
>>>
>>> On 07/05/20 4:07 am, Remi Forax wrote:
>>>>     @__inline__ static class Foo<V> {
>>>>       int x;
>>>>       Foo(int x) { this.x = x; }
>>>>     }
>>>>
>>>>     static void m(Foo foo) {
>>>>       System.out.println("inline");
>>>>     }
>>>>     static void m(Foo.ref foo) {
>>>>       System.out.println("ref");
>>>>     }
>>>>
>>>>     public static void main(String[] args) {
>>>>       List<Foo.ref<Integer>> list = List.of(new Foo<Integer>(3));
>>>>       list.stream().forEach(e -> m(e));
>>>>     }
>>>>
>>>> I don't even understand the error message when playing with parameterized ref of
>>>> an inline type.
>>>>
>>>> error: cannot select a static class from a parameterized type
>>>> Hello.java:19: error: incompatible types: incompatible parameter types in lambda
>>>> expression
>>>>       list.stream().forEach(e -> m(e));
>>>>                             ^
>>>>
>>>> regards,
> >>> R?mi


From john.r.rose at oracle.com  Sun May 10 01:00:43 2020
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 9 May 2020 18:00:43 -0700
Subject: CONSTANT_Class_info and L-envelopes
In-Reply-To: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
References: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
Message-ID: <D0132100-2A24-49D7-B941-B7DA7077DC81@oracle.com>

On May 8, 2020, at 6:15 AM, Frederic Parain <frederic.parain at oracle.com> wrote:
> 
> The problem with having two entries representing
> a symbolic reference to the same class is that there?s no guarantee
> that the resolution of these two entries will produce the same result.

This problem has existed in class files from day one,
since there is no rule of any sort which would exclude
duplicate CP entries.  I don?t see why we need to exclude
this extra kind of duplication, and the code for checking
it will distract us from other things.

? John

From srikanth.adayapalam at oracle.com  Sun May 10 12:32:54 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Sun, 10 May 2020 18:02:54 +0530
Subject: Lambda and parameterized ref of an inline type doesn't work well
In-Reply-To: <136811189.1028494.1589024005845.JavaMail.zimbra@u-pem.fr>
References: <1782085040.6556.1588804634413.JavaMail.zimbra@u-pem.fr>
 <fb477772-98fb-6a23-5b82-18d1ccea5a73@oracle.com>
 <1940132243.851285.1588950408593.JavaMail.zimbra@u-pem.fr>
 <56a7a881-36c9-b586-25ec-0deecbca5e13@oracle.com>
 <136811189.1028494.1589024005845.JavaMail.zimbra@u-pem.fr>
Message-ID: <bcd3ab6f-3068-1ba4-d0b2-81e2cdbc8c7a@oracle.com>



On 09/05/20 5:03 pm, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Srikanth" <srikanth.adayapalam at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoy?: Samedi 9 Mai 2020 02:52:26
>> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well
>> On 08/05/20 8:36 pm, Remi Forax wrote:
>>> [move to valhalla-dev]
>>>
>>> Hi Srikanth,
>>> This seems to fix the lambda bug but not the one with the enhanced for loop.
>> "not the one with enhanced for loop" - I'll take a look, but was this
>> reported earlier ?
>> Your wording seems to indicate so, but I seem to have missed the report
>> and am hearing it only now.
> I've mention it in the comment section of JDK-8244559, for me it comes from the same piece code but it's maybe another error.

Ah, you are right, I missed noticing that - anyway it is a separate 
problem so I will tackle it on a separate ticket.

Srikanth
>
>> In any case, I expect to have a fix soon. Thanks so much for testing and
>> the defect reports!
> No, thank you for your impressive work.
>
>> Srikanth
> R?mi
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8244559
>
>>> Here, the inline type is itself a generics so it should work as usual.
>>>
>>>     @__inline__ static class Foo<V> implements Iterable<V> {
>>>       int x = 3;
>>>       
>>>       public Iterator<V> iterator() {
>>>         return null;
>>>       }
>>>     }
>>>
>>>
>>>     public static void main(String[] args) {
>>>       Foo<String> foo = new Foo<String>();
>>>       for(var s: foo) {
>>>       }
>>>     }
>>>
>>>
>>> $javac Hello.java
>>> Hello.java:15: error: for-each not applicable to expression type
>>>       for(var s: foo) {
>>>                  ^
>>>     required: array or java.lang.Iterable
>>>     found:    Foo<String>
>>> 1 error
>>>
>>> regards,
>>> R?mi
>>>
>>> ----- Mail original -----
>>>> De: "Srikanth" <srikanth.adayapalam at oracle.com>
>>>> ?: "amber-dev" <amber-dev at openjdk.java.net>
>>>> Envoy?: Vendredi 8 Mai 2020 15:00:46
>>>> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well
>>>> Hello Remi,
>>>>
>>>> Thanks for the report - this should be fixed by the commit
>>>> https://github.com/openjdk/valhalla/commit/e586cdbe made for
>>>> https://bugs.openjdk.java.net/browse/JDK-8244559
>>>>
>>>> With this all three problems reported are solved and should work now.
>>>>
>>>> (The inline + record synthesized methods is open)
>>>>
>>>> Srikanth
>>>>
>>>> On 07/05/20 4:07 am, Remi Forax wrote:
>>>>>      @__inline__ static class Foo<V> {
>>>>>        int x;
>>>>>        Foo(int x) { this.x = x; }
>>>>>      }
>>>>>
>>>>>      static void m(Foo foo) {
>>>>>        System.out.println("inline");
>>>>>      }
>>>>>      static void m(Foo.ref foo) {
>>>>>        System.out.println("ref");
>>>>>      }
>>>>>
>>>>>      public static void main(String[] args) {
>>>>>        List<Foo.ref<Integer>> list = List.of(new Foo<Integer>(3));
>>>>>        list.stream().forEach(e -> m(e));
>>>>>      }
>>>>>
>>>>> I don't even understand the error message when playing with parameterized ref of
>>>>> an inline type.
>>>>>
>>>>> error: cannot select a static class from a parameterized type
>>>>> Hello.java:19: error: incompatible types: incompatible parameter types in lambda
>>>>> expression
>>>>>        list.stream().forEach(e -> m(e));
>>>>>                              ^
>>>>>
>>>>> regards,
>>>>> R?mi



From sadayapalam at openjdk.java.net  Mon May 11 05:56:44 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 11 May 2020 05:56:44 GMT
Subject: [lworld] RFR: 8244708: [lworld] CDS tests that bundle inline classes
 should also bundle reference projection classes.
Message-ID: <X0kLv58k75Xz2aoSNj2skf9oj1HgBxdSgHsjE1YBpsE=.2a5a63e2-7acf-46aa-92cf-2236ef4a06f7@github.com>

Patch to also jar up the $ref.class files.

-------------

Commit messages:
 - 8244708:  CDS tests that bundle inline classes should also bundle reference projection classes

Changes: https://git.openjdk.java.net/valhalla/pull/40/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/40/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244708
  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/40.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/40/head:pull/40

PR: https://git.openjdk.java.net/valhalla/pull/40


From dsimms at openjdk.java.net  Mon May 11 07:37:55 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 11 May 2020 07:37:55 GMT
Subject: [lworld] RFR: 8244708: [lworld] CDS tests that bundle inline
 classes should also bundle reference projection classes.
In-Reply-To: <X0kLv58k75Xz2aoSNj2skf9oj1HgBxdSgHsjE1YBpsE=.2a5a63e2-7acf-46aa-92cf-2236ef4a06f7@github.com>
References: <X0kLv58k75Xz2aoSNj2skf9oj1HgBxdSgHsjE1YBpsE=.2a5a63e2-7acf-46aa-92cf-2236ef4a06f7@github.com>
Message-ID: <cWuq2--8aTeUOl7JqESyQFY7nrPCttS1k-wc4SNJVOc=.2b4216f1-a31c-4e76-bf19-f70028ec243c@github.com>

On Mon, 11 May 2020 05:50:46 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Patch to also jar up the $ref.class files.

Looks good

-------------

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/40


From sadayapalam at openjdk.java.net  Mon May 11 07:45:56 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 11 May 2020 07:45:56 GMT
Subject: [Integrated] [lworld] RFR: 8244708: [lworld] CDS tests that
 bundle inline classes should also bundle reference projection classes.
In-Reply-To: <X0kLv58k75Xz2aoSNj2skf9oj1HgBxdSgHsjE1YBpsE=.2a5a63e2-7acf-46aa-92cf-2236ef4a06f7@github.com>
References: <X0kLv58k75Xz2aoSNj2skf9oj1HgBxdSgHsjE1YBpsE=.2a5a63e2-7acf-46aa-92cf-2236ef4a06f7@github.com>
Message-ID: <AK4kPLPUuTZfpa0M6JBe9JnMZFxXOLd0OIzgmfjOEZE=.99a0ad84-630d-4ba0-802d-31ead8968712@github.com>

On Mon, 11 May 2020 05:50:46 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Patch to also jar up the $ref.class files.

This pull request has now been integrated.

Changeset: bc0e6478
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bc0e6478
Stats:     4 lines in 4 files changed: 0 ins; 0 del; 4 mod

8244708: [lworld] CDS tests that bundle inline classes should also bundle reference projection classes.

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.java.net/valhalla/pull/40


From sadayapalam at openjdk.java.net  Mon May 11 11:19:48 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 11 May 2020 11:19:48 GMT
Subject: [lworld] RFR: 8244711: [lworld] Javac needs to tweak checks for
 interface implementation by an inline type.
Message-ID: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>

When javac needs to check if a class implements a particular interface, it should
check if the reference projection of the class is a subtype of the interface. (Rather
than checking if the concerned class is a subtype of the interface)

-------------

Commit messages:
 - 8244711: Javac needs to tweak checks for interface implementation by an inline type.

Changes: https://git.openjdk.java.net/valhalla/pull/41/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/41/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244711
  Stats: 178 lines in 9 files changed: 167 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/41.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/41/head:pull/41

PR: https://git.openjdk.java.net/valhalla/pull/41


From github.com+63007666+JimLaskey at openjdk.java.net  Mon May 11 12:08:46 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 11 May 2020 12:08:46 GMT
Subject: [lworld] RFR: 8244711: [lworld] Javac needs to tweak checks for
 interface implementation by an inline type.
In-Reply-To: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>
References: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>
Message-ID: <x3Vzj4EX-6y3eKpuaDvqqBaDNtmOfBWdkgv27zqsEvk=.5a52573e-570e-4ef6-bc97-a2cb5d64a9e8@github.com>

On Mon, 11 May 2020 11:13:53 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> When javac needs to check if a class implements a particular interface, it should
> check if the reference projection of the class is a subtype of the interface. (Rather
> than checking if the concerned class is a subtype of the interface)

Since asSuper is always called with a true checkReferenceProjection, why not drop the argument and rename as
asSuperWithProjection (or some such). If you introduce a need later for the false case then you can just call asSuper
directly. I.E., argument seems redundant.

test/langtools/tools/javac/valhalla/lworld-values/AutoCloseableTest.java line 57:

> 56:     }
> 57: }

Missing last newline.

test/langtools/tools/javac/valhalla/lworld-values/ConflictingSuperInterfaceTest.java line 15:

> 14:     }
> 15: }

Missing last newline.

test/langtools/tools/javac/valhalla/lworld-values/ConflictingSuperInterfaceTest.java line 1:

> 1: /*
> 2:  * @test /nodynamiccopyright/

Missing Copyright.

-------------

Changes requested by JimLaskey at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/valhalla/pull/41


From frederic.parain at oracle.com  Mon May 11 12:56:04 2020
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 11 May 2020 08:56:04 -0400
Subject: CONSTANT_Class_info and L-envelopes
In-Reply-To: <D0132100-2A24-49D7-B941-B7DA7077DC81@oracle.com>
References: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
 <D0132100-2A24-49D7-B941-B7DA7077DC81@oracle.com>
Message-ID: <FDD49095-07E3-4A34-BA72-00A1AAA9FC3F@oracle.com>



> On May 9, 2020, at 21:00, John Rose <john.r.rose at oracle.com> wrote:
> 
> On May 8, 2020, at 6:15 AM, Frederic Parain <frederic.parain at oracle.com> wrote:
>> 
>> The problem with having two entries representing
>> a symbolic reference to the same class is that there?s no guarantee
>> that the resolution of these two entries will produce the same result.
> 
> This problem has existed in class files from day one,
> since there is no rule of any sort which would exclude
> duplicate CP entries.  

I?m unpleasantly surprised, but it explains why I was not able to
find any rule about CP unicity in the spec.
So far, I?ve never seen a duplicate entry in class file generated
by javac, which aggressively optimize the constant pool (even going
to share UTF-8 entries used by Class and String entries).

> I don?t see why we need to exclude
> this extra kind of duplication, and the code for checking
> it will distract us from other things.
> 

With the dual notation, we just give users one more chance to shoot
themselves in the foot. But if the accepted approach to this problem
is to consider it as a user error, then I can remove the verification
code.

Fred



From sadayapalam at openjdk.java.net  Mon May 11 13:01:30 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 11 May 2020 13:01:30 GMT
Subject: [lworld] RFR: 8244711: [lworld] Javac needs to tweak checks for
 interface implementation by an inline type.
In-Reply-To: <x3Vzj4EX-6y3eKpuaDvqqBaDNtmOfBWdkgv27zqsEvk=.5a52573e-570e-4ef6-bc97-a2cb5d64a9e8@github.com>
References: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>
 <x3Vzj4EX-6y3eKpuaDvqqBaDNtmOfBWdkgv27zqsEvk=.5a52573e-570e-4ef6-bc97-a2cb5d64a9e8@github.com>
Message-ID: <xlIlIzY2KsOUwj0BPZjHjMH6BOwe2FLinjjOA9I0i7I=.881bfc96-d9bc-44d2-bb51-b3774ddb0ef0@github.com>

On Mon, 11 May 2020 12:06:24 GMT, Jim Laskey <github.com+63007666+JimLaskey at openjdk.org> wrote:

> Since asSuper is always called with a true checkReferenceProjection, why not drop the argument and rename as
> asSuperWithProjection (or some such). If you introduce a need later for the false case then you can just call asSuper
> directly. I.E., argument seems redundant.

I agree this looks strange. But rather than asSuperWithProjection, I have reworked it along the lines of existing
variants (isSubtype and friends) by making the original asSuper to be a three argument one and all existing calls to
the two args asSuper to be routed to the three arg full bodied asSuper with a 3rd argument value of false.

> test/langtools/tools/javac/valhalla/lworld-values/AutoCloseableTest.java line 57:
> 
>> 56:     }
>> 57: }
> 
> Missing last newline.

Will fix. Thanks

> test/langtools/tools/javac/valhalla/lworld-values/ConflictingSuperInterfaceTest.java line 15:
> 
>> 14:     }
>> 15: }
> 
> Missing last newline.

Will fix, thanks!

> test/langtools/tools/javac/valhalla/lworld-values/ConflictingSuperInterfaceTest.java line 1:
> 
>> 1: /*
>> 2:  * @test /nodynamiccopyright/
> 
> Missing Copyright.

This is intentional. In javac's negative tests we don't add a copyright, but a tag that says nodynamiccopyright.

I have forgotten the reason we do that, but that is the right behavior :)

-------------

PR: https://git.openjdk.java.net/valhalla/pull/41


From sadayapalam at openjdk.java.net  Mon May 11 13:14:08 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 11 May 2020 13:14:08 GMT
Subject: [lworld] [Rev 01] RFR: 8244711: [lworld] Javac needs to tweak
 checks for interface implementation by an inline type.
In-Reply-To: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>
References: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>
Message-ID: <RU53qYPmPowPtKopz30Cj2MQcUD0msFDAg89-jk-G4M=.22c2f49c-8f57-4314-9c43-d0d317281fcf@github.com>

> When javac needs to check if a class implements a particular interface, it should
> check if the reference projection of the class is a subtype of the interface. (Rather
> than checking if the concerned class is a subtype of the interface)

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate review comments from Jim Laskey.

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/41/files
  - new: https://git.openjdk.java.net/valhalla/pull/41/files/a2c689b3..f1bf9f8f

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/41/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/41/webrev.00-01

  Stats: 22 lines in 3 files changed: 9 ins; 8 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/41.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/41/head:pull/41

PR: https://git.openjdk.java.net/valhalla/pull/41


From github.com+63007666+JimLaskey at openjdk.java.net  Mon May 11 13:15:14 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 11 May 2020 13:15:14 GMT
Subject: [lworld] [Rev 01] RFR: 8244711: [lworld] Javac needs to tweak
 checks for interface implementation by an inline type.
In-Reply-To: <RU53qYPmPowPtKopz30Cj2MQcUD0msFDAg89-jk-G4M=.22c2f49c-8f57-4314-9c43-d0d317281fcf@github.com>
References: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>
 <RU53qYPmPowPtKopz30Cj2MQcUD0msFDAg89-jk-G4M=.22c2f49c-8f57-4314-9c43-d0d317281fcf@github.com>
Message-ID: <bXD_PVjUZs5nIFgH53WBS2BPfzuQgKPPeMLbkpjYuTI=.1686612b-6437-4a1f-926e-623c961f59e8@github.com>

On Mon, 11 May 2020 13:14:08 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> When javac needs to check if a class implements a particular interface, it should
>> check if the reference projection of the class is a subtype of the interface. (Rather
>> than checking if the concerned class is a subtype of the interface)
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Jim Laskey.

Marked as reviewed by JimLaskey at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/41


From sadayapalam at openjdk.java.net  Mon May 11 13:44:16 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 11 May 2020 13:44:16 GMT
Subject: [Integrated] [lworld] RFR: 8244711: [lworld] Javac needs to tweak
 checks for interface implementation by an inline type.
In-Reply-To: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>
References: <VtY7KewPUgm1RkA3QUbAu7x8o_DqaRxg2tFbGba3fcg=.00aa8a8c-c601-4b26-9576-915b994f43ff@github.com>
Message-ID: <Io2331Yzu_BQD7GMlV1FfcdOzZKtac3aYu0667KlK04=.d942b512-3df0-4906-bd77-750026aa2fdf@github.com>

On Mon, 11 May 2020 11:13:53 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> When javac needs to check if a class implements a particular interface, it should
> check if the reference projection of the class is a subtype of the interface. (Rather
> than checking if the concerned class is a subtype of the interface)

This pull request has now been integrated.

Changeset: ec1930c0
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ec1930c0
Stats:     179 lines in 9 files changed: 4 ins; 168 del; 7 mod

8244711: [lworld] Javac needs to tweak checks for interface implementation by an inline type.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/41


From srikanth.adayapalam at oracle.com  Mon May 11 13:50:33 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Mon, 11 May 2020 19:20:33 +0530
Subject: Lambda and parameterized ref of an inline type doesn't work well
In-Reply-To: <1940132243.851285.1588950408593.JavaMail.zimbra@u-pem.fr>
References: <1782085040.6556.1588804634413.JavaMail.zimbra@u-pem.fr>
 <fb477772-98fb-6a23-5b82-18d1ccea5a73@oracle.com>
 <1940132243.851285.1588950408593.JavaMail.zimbra@u-pem.fr>
Message-ID: <b1e7cc87-aac4-cc6c-e4a0-b093aea912d3@oracle.com>



On 08/05/20 8:36 pm, Remi Forax wrote:
> [move to valhalla-dev]
>
> Hi Srikanth,
> This seems to fix the lambda bug but not the one with the enhanced for loop.
> Here, the inline type is itself a generics so it should work as usual.

Sorry about the confusion and overlooking this case. This should work now
with https://github.com/openjdk/valhalla/pull/41/ being integrated.

Thanks!
Srikanth

>
>    @__inline__ static class Foo<V> implements Iterable<V> {
>      int x = 3;
>      
>      public Iterator<V> iterator() {
>        return null;
>      }
>    }
>
>
>    public static void main(String[] args) {
>      Foo<String> foo = new Foo<String>();
>      for(var s: foo) {
>      }
>    }
>
>
> $javac Hello.java
> Hello.java:15: error: for-each not applicable to expression type
>      for(var s: foo) {
>                 ^
>    required: array or java.lang.Iterable
>    found:    Foo<String>
> 1 error
>
> regards,
> R?mi
>
> ----- Mail original -----
>> De: "Srikanth" <srikanth.adayapalam at oracle.com>
>> ?: "amber-dev" <amber-dev at openjdk.java.net>
>> Envoy?: Vendredi 8 Mai 2020 15:00:46
>> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well
>> Hello Remi,
>>
>> Thanks for the report - this should be fixed by the commit
>> https://github.com/openjdk/valhalla/commit/e586cdbe made for
>> https://bugs.openjdk.java.net/browse/JDK-8244559
>>
>> With this all three problems reported are solved and should work now.
>>
>> (The inline + record synthesized methods is open)
>>
>> Srikanth
>>
>> On 07/05/20 4:07 am, Remi Forax wrote:
>>>     @__inline__ static class Foo<V> {
>>>       int x;
>>>       Foo(int x) { this.x = x; }
>>>     }
>>>
>>>     static void m(Foo foo) {
>>>       System.out.println("inline");
>>>     }
>>>     static void m(Foo.ref foo) {
>>>       System.out.println("ref");
>>>     }
>>>
>>>     public static void main(String[] args) {
>>>       List<Foo.ref<Integer>> list = List.of(new Foo<Integer>(3));
>>>       list.stream().forEach(e -> m(e));
>>>     }
>>>
>>> I don't even understand the error message when playing with parameterized ref of
>>> an inline type.
>>>
>>> error: cannot select a static class from a parameterized type
>>> Hello.java:19: error: incompatible types: incompatible parameter types in lambda
>>> expression
>>>       list.stream().forEach(e -> m(e));
>>>                             ^
>>>
>>> regards,
>>> R?mi



From forax at univ-mlv.fr  Mon May 11 20:52:27 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 11 May 2020 22:52:27 +0200 (CEST)
Subject: CONSTANT_Class_info and L-envelopes
In-Reply-To: <FDD49095-07E3-4A34-BA72-00A1AAA9FC3F@oracle.com>
References: <B987F64B-6C38-4914-81F7-407FA0BD554B@oracle.com>
 <D0132100-2A24-49D7-B941-B7DA7077DC81@oracle.com>
 <FDD49095-07E3-4A34-BA72-00A1AAA9FC3F@oracle.com>
Message-ID: <1492822710.701945.1589230347012.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Frederic Parain" <frederic.parain at oracle.com>
> ?: "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Lundi 11 Mai 2020 14:56:04
> Objet: Re: CONSTANT_Class_info and L-envelopes

>> On May 9, 2020, at 21:00, John Rose <john.r.rose at oracle.com> wrote:
>> 
>> On May 8, 2020, at 6:15 AM, Frederic Parain <frederic.parain at oracle.com> wrote:
>>> 
>>> The problem with having two entries representing
>>> a symbolic reference to the same class is that there?s no guarantee
>>> that the resolution of these two entries will produce the same result.
>> 
>> This problem has existed in class files from day one,
>> since there is no rule of any sort which would exclude
>> duplicate CP entries.
> 
> I?m unpleasantly surprised, but it explains why I was not able to
> find any rule about CP unicity in the spec.
> So far, I?ve never seen a duplicate entry in class file generated
> by javac, which aggressively optimize the constant pool (even going
> to share UTF-8 entries used by Class and String entries).

javac or ASM maintain a hash table of previously seen constants, so there will be no duplicate entries.
some java.lang.instrument agents do quick patch of the class file and append the constants directly at the end of the constant pool without testing if those constants already exist because being just a little faster per class adds up when you have thousands of classes to transform/redefine.  

> 
>> I don?t see why we need to exclude
>> this extra kind of duplication, and the code for checking
>> it will distract us from other things.
>> 
> 
> With the dual notation, we just give users one more chance to shoot
> themselves in the foot. But if the accepted approach to this problem
> is to consider it as a user error, then I can remove the verification
> code.
> 
> Fred

R?mi



From forax at univ-mlv.fr  Mon May 11 21:02:03 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 11 May 2020 23:02:03 +0200 (CEST)
Subject: System.identityHashCode
In-Reply-To: <A044A27C-2ED2-4312-A45B-C6AF4D7A6798@oracle.com>
References: <352804674.930089.1588978555643.JavaMail.zimbra@u-pem.fr>
 <A044A27C-2ED2-4312-A45B-C6AF4D7A6798@oracle.com>
Message-ID: <1976252917.703332.1589230923826.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Samedi 9 Mai 2020 01:31:51
> Objet: Re: System.identityHashCode

> That?s a lame but correct implementation.

yes

> Making it higher quality will require some effort. An ideal implementation would make every bit of the output depend
> on every bit of the input that could affect the outcome of the acmp bytecode.
> And it would be fast. Therefore we have trade-offs to make.
> 

I was thinking about doing a reduce using a xor between the primitive fields and the klass,
but i've discovered that reduceLanes(XOR) provided by the panama vector API is not one AVX operation :(

R?mi


>> On May 8, 2020, at 3:56 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> ?Hi all,
>> it seems to me that for the current implementation the value returned by
>> identityHashCode doesn't depend on the field values on the inlining classes but
>> only the class.
>> 
>> What is the rational for such choice (if i'm right) ?
>> 
>> regards,
> > R?mi


From john.r.rose at oracle.com  Mon May 11 21:35:18 2020
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 11 May 2020 14:35:18 -0700
Subject: System.identityHashCode
In-Reply-To: <1976252917.703332.1589230923826.JavaMail.zimbra@u-pem.fr>
References: <352804674.930089.1588978555643.JavaMail.zimbra@u-pem.fr>
 <A044A27C-2ED2-4312-A45B-C6AF4D7A6798@oracle.com>
 <1976252917.703332.1589230923826.JavaMail.zimbra@u-pem.fr>
Message-ID: <7155A404-6575-4D7C-BB95-1DAABC63273D@oracle.com>

On May 11, 2020, at 2:02 PM, forax at univ-mlv.fr wrote:
> 
> I was thinking about doing a reduce using a xor between the primitive fields and the klass,
> but i've discovered that reduceLanes(XOR) provided by the panama vector API is not one AVX operation :(

The best cross-lane bit-mixer is AES step, followed by
long multiply.  Reduce-lanes XOR is many times worse.

From john.r.rose at oracle.com  Mon May 11 23:08:15 2020
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 11 May 2020 16:08:15 -0700
Subject: System.identityHashCode
In-Reply-To: <7155A404-6575-4D7C-BB95-1DAABC63273D@oracle.com>
References: <352804674.930089.1588978555643.JavaMail.zimbra@u-pem.fr>
 <A044A27C-2ED2-4312-A45B-C6AF4D7A6798@oracle.com>
 <1976252917.703332.1589230923826.JavaMail.zimbra@u-pem.fr>
 <7155A404-6575-4D7C-BB95-1DAABC63273D@oracle.com>
Message-ID: <E65E0CB2-8E2E-4DCF-933F-8B5F5EABA4C4@oracle.com>

On May 11, 2020, at 2:35 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On May 11, 2020, at 2:02 PM, forax at univ-mlv.fr wrote:
>> 
>> I was thinking about doing a reduce using a xor between the primitive fields and the klass,
>> but i've discovered that reduceLanes(XOR) provided by the panama vector API is not one AVX operation :(
> 
> The best cross-lane bit-mixer is AES step, followed by
> long multiply.  Reduce-lanes XOR is many times worse.

P.S. Multiply comes in CLMUL flavor also (H/T Doug Lea).
In any case, multiply operations work best if you collect
high and low halves and fold them together.  Roughly
similarly, AES step is far stronger if it is done at depth
two.  Single AES step fails smhasher but passes when
doubled.  AES mixes 128 bits at a time, which gives it
a specific edge over multiply.  These considerations
feed into my basic position that hash codes should
be ?cook?s choice? by the JVM, rather than specified
forever in Javadoc.

See https://openjdk.java.net/jeps/8201462.



From sadayapalam at openjdk.java.net  Tue May 12 05:19:50 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 12 May 2020 05:19:50 GMT
Subject: [lworld] RFR: 8230082: [lworld] Volatile field declaration in inline
 class fails with ClassFormatError
Message-ID: <qjmU5U7soF2egz1b0CEwUfdw5UpJLFkXtyoWvnhYtWU=.49447f01-1a1f-44a5-a686-1c0a0c77080f@github.com>

Jim, could you please review this small fix ?

Basically while checking that both FINAL and VOLATILE are not simultaneously
on, we should also check implicitly computed flags.

(Perhaps all calls to disjoint should consider implicit flags - but after
spending some time, I couldn't construct other problematic scenarios, so
decided to mind my business and limit it to the case at hand)

-------------

Commit messages:
 - 8230082: Volatile field declaration in inline class fails with ClassFormatError

Changes: https://git.openjdk.java.net/valhalla/pull/43/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/43/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8230082
  Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/43.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/43/head:pull/43

PR: https://git.openjdk.java.net/valhalla/pull/43


From sadayapalam at openjdk.java.net  Tue May 12 05:19:34 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 12 May 2020 05:19:34 GMT
Subject: [lworld] RFR: 8244235: java.lang.NoSuchFieldError: this when
 initializing an inner class inside an inline type
Message-ID: <DOjLtjSIeKnDlKrwncn3k_RyG-VSJG9_VaAltAt17Vk=.a17648b1-089a-46bd-922d-8b778f9585c1@github.com>

Jim, Thanks for reviewing this small fix.

Basically, javac mistakenly treats references to 'this' as an instance field.
Fix is to handle this particular case specially and return the value factory
product which is the proxy for 'this' in the inline factory.

I renamed a method suitably for better clarity. Of the three call sites only
one needed change. It is implausible in the other two sites that the symbol
involved is 'this' (since 'this' cannot be assigned to and qualified this would
have been lowered already)

-------------

Commit messages:
 - 8244235: java.lang.NoSuchFieldError: this when initializing an inner class inside an inline type

Changes: https://git.openjdk.java.net/valhalla/pull/42/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/42/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244235
  Stats: 59 lines in 2 files changed: 54 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/42.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/42/head:pull/42

PR: https://git.openjdk.java.net/valhalla/pull/42


From forax at univ-mlv.fr  Tue May 12 10:00:03 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 12 May 2020 12:00:03 +0200 (CEST)
Subject: Lambda and parameterized ref of an inline type doesn't work well
In-Reply-To: <b1e7cc87-aac4-cc6c-e4a0-b093aea912d3@oracle.com>
References: <1782085040.6556.1588804634413.JavaMail.zimbra@u-pem.fr>
 <fb477772-98fb-6a23-5b82-18d1ccea5a73@oracle.com>
 <1940132243.851285.1588950408593.JavaMail.zimbra@u-pem.fr>
 <b1e7cc87-aac4-cc6c-e4a0-b093aea912d3@oracle.com>
Message-ID: <1111934649.936627.1589277603043.JavaMail.zimbra@u-pem.fr>

yes !
it fixes the issue.

R?mi

----- Mail original -----
> De: "Srikanth" <srikanth.adayapalam at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Lundi 11 Mai 2020 15:50:33
> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well

> On 08/05/20 8:36 pm, Remi Forax wrote:
>> [move to valhalla-dev]
>>
>> Hi Srikanth,
>> This seems to fix the lambda bug but not the one with the enhanced for loop.
>> Here, the inline type is itself a generics so it should work as usual.
> 
> Sorry about the confusion and overlooking this case. This should work now
> with https://github.com/openjdk/valhalla/pull/41/ being integrated.
> 
> Thanks!
> Srikanth
> 
>>
>>    @__inline__ static class Foo<V> implements Iterable<V> {
>>      int x = 3;
>>      
>>      public Iterator<V> iterator() {
>>        return null;
>>      }
>>    }
>>
>>
>>    public static void main(String[] args) {
>>      Foo<String> foo = new Foo<String>();
>>      for(var s: foo) {
>>      }
>>    }
>>
>>
>> $javac Hello.java
>> Hello.java:15: error: for-each not applicable to expression type
>>      for(var s: foo) {
>>                 ^
>>    required: array or java.lang.Iterable
>>    found:    Foo<String>
>> 1 error
>>
>> regards,
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Srikanth" <srikanth.adayapalam at oracle.com>
>>> ?: "amber-dev" <amber-dev at openjdk.java.net>
>>> Envoy?: Vendredi 8 Mai 2020 15:00:46
>>> Objet: Re: Lambda and parameterized ref of an inline type doesn't work well
>>> Hello Remi,
>>>
>>> Thanks for the report - this should be fixed by the commit
>>> https://github.com/openjdk/valhalla/commit/e586cdbe made for
>>> https://bugs.openjdk.java.net/browse/JDK-8244559
>>>
>>> With this all three problems reported are solved and should work now.
>>>
>>> (The inline + record synthesized methods is open)
>>>
>>> Srikanth
>>>
>>> On 07/05/20 4:07 am, Remi Forax wrote:
>>>>     @__inline__ static class Foo<V> {
>>>>       int x;
>>>>       Foo(int x) { this.x = x; }
>>>>     }
>>>>
>>>>     static void m(Foo foo) {
>>>>       System.out.println("inline");
>>>>     }
>>>>     static void m(Foo.ref foo) {
>>>>       System.out.println("ref");
>>>>     }
>>>>
>>>>     public static void main(String[] args) {
>>>>       List<Foo.ref<Integer>> list = List.of(new Foo<Integer>(3));
>>>>       list.stream().forEach(e -> m(e));
>>>>     }
>>>>
>>>> I don't even understand the error message when playing with parameterized ref of
>>>> an inline type.
>>>>
>>>> error: cannot select a static class from a parameterized type
>>>> Hello.java:19: error: incompatible types: incompatible parameter types in lambda
>>>> expression
>>>>       list.stream().forEach(e -> m(e));
>>>>                             ^
>>>>
>>>> regards,
> >>> R?mi


From github.com+63007666+JimLaskey at openjdk.java.net  Tue May 12 11:54:29 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 12 May 2020 11:54:29 GMT
Subject: [lworld] RFR: 8244235: java.lang.NoSuchFieldError: this when
 initializing an inner class inside an inline type
In-Reply-To: <DOjLtjSIeKnDlKrwncn3k_RyG-VSJG9_VaAltAt17Vk=.a17648b1-089a-46bd-922d-8b778f9585c1@github.com>
References: <DOjLtjSIeKnDlKrwncn3k_RyG-VSJG9_VaAltAt17Vk=.a17648b1-089a-46bd-922d-8b778f9585c1@github.com>
Message-ID: <rpqTqapMJOds1Hak-gh255Ro2Y2onioDGhhtpTJI5pk=.1054441b-af60-4efa-b7b8-a7c83f80ae01@github.com>

On Tue, 12 May 2020 02:56:59 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, Thanks for reviewing this small fix.
> 
> Basically, javac mistakenly treats references to 'this' as an instance field.
> Fix is to handle this particular case specially and return the value factory
> product which is the proxy for 'this' in the inline factory.
> 
> I renamed a method suitably for better clarity. Of the three call sites only
> one needed change. It is implausible in the other two sites that the symbol
> involved is 'this' (since 'this' cannot be assigned to and qualified this would
> have been lowered already)

Marked as reviewed by JimLaskey at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/42


From github.com+63007666+JimLaskey at openjdk.java.net  Tue May 12 11:56:15 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 12 May 2020 11:56:15 GMT
Subject: [lworld] RFR: 8230082: [lworld] Volatile field declaration in
 inline class fails with ClassFormatError
In-Reply-To: <qjmU5U7soF2egz1b0CEwUfdw5UpJLFkXtyoWvnhYtWU=.49447f01-1a1f-44a5-a686-1c0a0c77080f@github.com>
References: <qjmU5U7soF2egz1b0CEwUfdw5UpJLFkXtyoWvnhYtWU=.49447f01-1a1f-44a5-a686-1c0a0c77080f@github.com>
Message-ID: <5HLtZ36dzPN3xU4CiaZK1TToDok-bR5qKaLij-3r3dA=.eb9c5d32-b6d6-4a07-a772-2e54d19c8d4a@github.com>

On Tue, 12 May 2020 04:11:12 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, could you please review this small fix ?
> 
> Basically while checking that both FINAL and VOLATILE are not simultaneously
> on, we should also check implicitly computed flags.
> 
> (Perhaps all calls to disjoint should consider implicit flags - but after
> spending some time, I couldn't construct other problematic scenarios, so
> decided to mind my business and limit it to the case at hand)

Marked as reviewed by JimLaskey at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/43


From sadayapalam at openjdk.java.net  Tue May 12 12:05:53 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 12 May 2020 12:05:53 GMT
Subject: [Integrated] [lworld] RFR: 8244235: java.lang.NoSuchFieldError:
 this when initializing an inner class inside an inline type
In-Reply-To: <DOjLtjSIeKnDlKrwncn3k_RyG-VSJG9_VaAltAt17Vk=.a17648b1-089a-46bd-922d-8b778f9585c1@github.com>
References: <DOjLtjSIeKnDlKrwncn3k_RyG-VSJG9_VaAltAt17Vk=.a17648b1-089a-46bd-922d-8b778f9585c1@github.com>
Message-ID: <zat6SrjJc7ELWjPQv2hjw-NK5ahMuurrSPfAji_L5AU=.b40c956b-c88d-4a12-b0d3-60d426e36884@github.com>

On Tue, 12 May 2020 02:56:59 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, Thanks for reviewing this small fix.
> 
> Basically, javac mistakenly treats references to 'this' as an instance field.
> Fix is to handle this particular case specially and return the value factory
> product which is the proxy for 'this' in the inline factory.
> 
> I renamed a method suitably for better clarity. Of the three call sites only
> one needed change. It is implausible in the other two sites that the symbol
> involved is 'this' (since 'this' cannot be assigned to and qualified this would
> have been lowered already)

This pull request has now been integrated.

Changeset: 27858b06
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/27858b06
Stats:     59 lines in 2 files changed: 0 ins; 54 del; 5 mod

8244235: java.lang.NoSuchFieldError: this when initializing an inner class inside an inline type

-------------

PR: https://git.openjdk.java.net/valhalla/pull/42


From sadayapalam at openjdk.java.net  Tue May 12 12:14:41 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 12 May 2020 12:14:41 GMT
Subject: [Integrated] [lworld] RFR: 8230082: [lworld] Volatile field
 declaration in inline class fails with ClassFormatError
In-Reply-To: <qjmU5U7soF2egz1b0CEwUfdw5UpJLFkXtyoWvnhYtWU=.49447f01-1a1f-44a5-a686-1c0a0c77080f@github.com>
References: <qjmU5U7soF2egz1b0CEwUfdw5UpJLFkXtyoWvnhYtWU=.49447f01-1a1f-44a5-a686-1c0a0c77080f@github.com>
Message-ID: <8BHIlGEd1f3kLk2mAsM-S02EBmwdm1Z2C1aShBvkaLU=.d7de3b85-abdb-4081-a24c-a63ab819efda@github.com>

On Tue, 12 May 2020 04:11:12 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, could you please review this small fix ?
> 
> Basically while checking that both FINAL and VOLATILE are not simultaneously
> on, we should also check implicitly computed flags.
> 
> (Perhaps all calls to disjoint should consider implicit flags - but after
> spending some time, I couldn't construct other problematic scenarios, so
> decided to mind my business and limit it to the case at hand)

This pull request has now been integrated.

Changeset: 46a60aec
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/46a60aec
Stats:     22 lines in 3 files changed: 0 ins; 21 del; 1 mod

8230082: [lworld] Volatile field declaration in inline class fails with ClassFormatError

-------------

PR: https://git.openjdk.java.net/valhalla/pull/43


From dsimms at openjdk.java.net  Wed May 13 09:02:25 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 13 May 2020 09:02:25 GMT
Subject: [lworld] RFR: 8244810: [lworld] Decommission
 arrayStorageProperties from Klass:array_klass() et el
In-Reply-To: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
References: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
Message-ID: <w_qOf7X4YE-8RmsLBLr7iufkaNiYdGBAvpT8edvVqQI=.13b90f7a-4db1-4013-96f9-8d5cf2f37ec8@github.com>

On Wed, 13 May 2020 08:56:01 GMT, David Simms <dsimms at openjdk.org> wrote:

> First part of LW2 to LW3 arrays

Partially backing out of 8222525 (https://github.com/openjdk/valhalla/commit/f49762698cfc350280eca28cd3daf67f0a000e9f)

-------------

PR: https://git.openjdk.java.net/valhalla/pull/44


From sadayapalam at openjdk.java.net  Wed May 13 09:04:53 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 13 May 2020 09:04:53 GMT
Subject: [lworld] RFR: 8243317:
 jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java fails multiple tests
Message-ID: <QcnH6kjDQC89hR4Nn1Mp_7Gmw2DMuKrXOyvyxATWiOY=.4788b2e1-696f-4c82-b34a-b898419f5309@github.com>

Jim, Could you please review this test only fix to address a test failure ?

Basically, this javadoc test is surprised by the "implements IdentityObject" detail
in the output as it is not prepared for it.

(Note however that this is a temporary measure. As a part of the upcoming work for
https://bugs.openjdk.java.net/browse/JDK-8242612, we will also be ensuring that
the new super top types stay implicit and don't get to surface in javadoc outputs)

-------------

Commit messages:
 - 8243317: jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java fails multiple tests

Changes: https://git.openjdk.java.net/valhalla/pull/45/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/45/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243317
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/45.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/45/head:pull/45

PR: https://git.openjdk.java.net/valhalla/pull/45


From dsimms at openjdk.java.net  Wed May 13 09:02:25 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 13 May 2020 09:02:25 GMT
Subject: [lworld] RFR: 8244810: [lworld] Decommission arrayStorageProperties
 from Klass:array_klass() et el
Message-ID: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>

First part of LW2 to LW3 arrays

-------------

Commit messages:
 - [lworld] Decommission arrayStorageProperties from Klass:array_klass() et el

Changes: https://git.openjdk.java.net/valhalla/pull/44/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/44/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244810
  Stats: 205 lines in 25 files changed: 30 ins; 57 del; 118 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/44.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/44/head:pull/44

PR: https://git.openjdk.java.net/valhalla/pull/44


From sadayapalam at openjdk.java.net  Wed May 13 09:07:16 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 13 May 2020 09:07:16 GMT
Subject: [Integrated] [lworld] RFR: 8243317:
 jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java fails multiple tests
In-Reply-To: <QcnH6kjDQC89hR4Nn1Mp_7Gmw2DMuKrXOyvyxATWiOY=.4788b2e1-696f-4c82-b34a-b898419f5309@github.com>
References: <QcnH6kjDQC89hR4Nn1Mp_7Gmw2DMuKrXOyvyxATWiOY=.4788b2e1-696f-4c82-b34a-b898419f5309@github.com>
Message-ID: <U4kCwwXgujGlXFLoHXRPnU3qhLzRdH-T-5ts7r9l7iY=.dff3a5d5-5525-48f9-9973-b5a782e08986@github.com>

On Wed, 13 May 2020 08:59:11 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, Could you please review this test only fix to address a test failure ?
> 
> Basically, this javadoc test is surprised by the "implements IdentityObject" detail
> in the output as it is not prepared for it.
> 
> (Note however that this is a temporary measure. As a part of the upcoming work for
> https://bugs.openjdk.java.net/browse/JDK-8242612, we will also be ensuring that
> the new super top types stay implicit and don't get to surface in javadoc outputs)

This pull request has now been integrated.

Changeset: f87a1b41
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f87a1b41
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8243317: jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java fails multiple tests

-------------

PR: https://git.openjdk.java.net/valhalla/pull/45


From dsimms at openjdk.java.net  Wed May 13 09:54:31 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 13 May 2020 09:54:31 GMT
Subject: [lworld] [Rev 01] RFR: 8244810: [lworld] Decommission
 arrayStorageProperties from Klass:array_klass() et el
In-Reply-To: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
References: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
Message-ID: <tQF2FkKwpG2ITlAz3hccp8REq1SjTDenOc05Aw8Lny4=.3c04f1e2-578f-49c5-b420-d3ca824d5465@github.com>

> First part of LW2 to LW3 arrays

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Copyright syntax

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/44/files
  - new: https://git.openjdk.java.net/valhalla/pull/44/files/a232b564..ec8c49cc

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/44/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/44/webrev.00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/44.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/44/head:pull/44

PR: https://git.openjdk.java.net/valhalla/pull/44


From fparain at openjdk.java.net  Wed May 13 16:23:24 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 13 May 2020 16:23:24 GMT
Subject: [lworld] [Rev 01] RFR: 8244810: [lworld] Decommission
 arrayStorageProperties from Klass:array_klass() et el
In-Reply-To: <tQF2FkKwpG2ITlAz3hccp8REq1SjTDenOc05Aw8Lny4=.3c04f1e2-578f-49c5-b420-d3ca824d5465@github.com>
References: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
 <tQF2FkKwpG2ITlAz3hccp8REq1SjTDenOc05Aw8Lny4=.3c04f1e2-578f-49c5-b420-d3ca824d5465@github.com>
Message-ID: <sN9sCOJVnl4xs3XWj7irao04EYcYr6IAOhIVyRNDqJI=.11d64306-7d4f-4150-b1af-326307caf987@github.com>

On Wed, 13 May 2020 09:54:31 GMT, David Simms <dsimms at openjdk.org> wrote:

>> First part of LW2 to LW3 arrays
>
> David Simms has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright syntax

Looks like a good start to remove `ArrayStorageProperties`.
My only strong concern is in `oopFactory.cpp` (see inline comment).

Fred

src/hotspot/share/memory/oopFactory.cpp line 155:

> 154:   ValueArrayKlass* vak = ValueArrayKlass::cast(array->klass());
> 155:   objArrayHandle oarray = new_objArray_handle(vak->element_klass()->super(),
> 156:                                               array->length(), CHECK_(objArrayHandle()));

With the evolving model, it is not guaranteed that the direct super type will be an inline type, it might be safer to
create an `Object[]` instead.

src/hotspot/share/oops/arrayStorageProperties.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

(Comment for the whole file)
I understand this is the first stage of a set of complex changes to remove the `ArrayStorageProperties` code, but
cleaning up the `ArrayStorageProperties` as things are getting removed might help to see progress (and would make
reviews easier). For instance:
  - `clear_flattened()`
  - `set_flattened()`
  - `set_null_free()`
  - `for_signature(Symbol* sig)`
seem to not be used anymore and could be removed.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/44


From frederic.parain at oracle.com  Wed May 13 17:07:04 2020
From: frederic.parain at oracle.com (Frederic Parain)
Date: Wed, 13 May 2020 13:07:04 -0400
Subject: [lworld] [Rev 01] RFR: 8244810: [lworld] Decommission
 arrayStorageProperties from Klass:array_klass() et el
In-Reply-To: <sN9sCOJVnl4xs3XWj7irao04EYcYr6IAOhIVyRNDqJI=.11d64306-7d4f-4150-b1af-326307caf987@github.com>
References: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
 <tQF2FkKwpG2ITlAz3hccp8REq1SjTDenOc05Aw8Lny4=.3c04f1e2-578f-49c5-b420-d3ca824d5465@github.com>
 <sN9sCOJVnl4xs3XWj7irao04EYcYr6IAOhIVyRNDqJI=.11d64306-7d4f-4150-b1af-326307caf987@github.com>
Message-ID: <20B88C13-0428-45A0-9DDC-FC66E09AA1EE@oracle.com>



> On May 13, 2020, at 12:23, Frederic Parain <fparain at openjdk.java.net> wrote:
> 
> On Wed, 13 May 2020 09:54:31 GMT, David Simms <dsimms at openjdk.org> wrote:
> 
>>> First part of LW2 to LW3 arrays
>> 
>> David Simms has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Copyright syntax
> 
> Looks like a good start to remove `ArrayStorageProperties`.
> My only strong concern is in `oopFactory.cpp` (see inline comment).
> 
> Fred
> 
> src/hotspot/share/memory/oopFactory.cpp line 155:
> 
>> 154:   ValueArrayKlass* vak = ValueArrayKlass::cast(array->klass());
>> 155:   objArrayHandle oarray = new_objArray_handle(vak->element_klass()->super(),
>> 156:                                               array->length(), CHECK_(objArrayHandle()));
> 
> With the evolving model, it is not guaranteed that the direct super type will be an inline type, it might be safer to
> create an `Object[]` instead.

Correction:
"With the evolving model, it is not guaranteed that the direct super type will *not* be an inline type, it might be safer
to create an `Object[]` instead.?

Fred

> 
> src/hotspot/share/oops/arrayStorageProperties.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> (Comment for the whole file)
> I understand this is the first stage of a set of complex changes to remove the `ArrayStorageProperties` code, but
> cleaning up the `ArrayStorageProperties` as things are getting removed might help to see progress (and would make
> reviews easier). For instance:
>  - `clear_flattened()`
>  - `set_flattened()`
>  - `set_null_free()`
>  - `for_signature(Symbol* sig)`
> seem to not be used anymore and could be removed.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/valhalla/pull/44



From sadayapalam at openjdk.java.net  Thu May 14 01:42:08 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 14 May 2020 01:42:08 GMT
Subject: [lworld] RFR: 8244796: [lworld] Javac does not compile
 test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
In-Reply-To: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
References: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
Message-ID: <lHLUwrgadJF8fkhW8fd03fCgytb5gFTbhSRefog8s_c=.a6804e23-e168-41f4-9ac6-05639a0dc45d@github.com>

On Thu, 14 May 2020 01:34:10 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Summary: Implement temporary typing rules for value class literals, these being:
> 
>     o Given a value class V that implements an interface I
>         - Class<V>, Class<? extends V>, Class<? super V> are all malformed for the time being.
>         - V.class and v.getClass() are to be typed temporarily as Class<? extends Object & I>

/solves 8244799

-------------

PR: https://git.openjdk.java.net/valhalla/pull/46


From sadayapalam at openjdk.java.net  Thu May 14 01:40:04 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 14 May 2020 01:40:04 GMT
Subject: [lworld] RFR: 8244796: [lworld] Javac does not compile
 test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
Message-ID: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>

Summary: Implement temporary typing rules for value class literals, these being:

    o Given a value class V that implements an interface I
        - Class<V>, Class<? extends V>, Class<? super V> are all malformed for the time being.
        - V.class and v.getClass() are to be typed temporarily as Class<? extends Object & I>

-------------

Commit messages:
 - Additional fixes for typing of value class literals.
 - Merge branch 'JDK-8244796' of https://github.com/sadayapalam/valhalla into JDK-8244796
 - 8244796: Javac does not compile test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
 - 8244796: Javac does not compile test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore

Changes: https://git.openjdk.java.net/valhalla/pull/46/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/46/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244796
  Stats: 91 lines in 6 files changed: 85 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/46.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/46/head:pull/46

PR: https://git.openjdk.java.net/valhalla/pull/46


From dsimms at openjdk.java.net  Thu May 14 06:43:09 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 14 May 2020 06:43:09 GMT
Subject: [lworld] [Rev 01] RFR: 8244810: [lworld] Decommission
 arrayStorageProperties from Klass:array_klass() et el
In-Reply-To: <sN9sCOJVnl4xs3XWj7irao04EYcYr6IAOhIVyRNDqJI=.11d64306-7d4f-4150-b1af-326307caf987@github.com>
References: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
 <tQF2FkKwpG2ITlAz3hccp8REq1SjTDenOc05Aw8Lny4=.3c04f1e2-578f-49c5-b420-d3ca824d5465@github.com>
 <sN9sCOJVnl4xs3XWj7irao04EYcYr6IAOhIVyRNDqJI=.11d64306-7d4f-4150-b1af-326307caf987@github.com>
Message-ID: <gHuA4zmRXbHpVTjfxjzHRt2TYH_lzvAFoOOdb86zrI4=.864581bb-80ff-4afc-96ae-dfe4d64722a4@github.com>

On Wed, 13 May 2020 15:54:18 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> David Simms has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright syntax
>
> src/hotspot/share/memory/oopFactory.cpp line 155:
> 
>> 154:   ValueArrayKlass* vak = ValueArrayKlass::cast(array->klass());
>> 155:   objArrayHandle oarray = new_objArray_handle(vak->element_klass()->super(),
>> 156:                                               array->length(), CHECK_(objArrayHandle()));
> 
> With the evolving model, it is not guaranteed that the direct super type will not be an inline type, it might be safer
> to create an `Object[]` instead.

Totally agree.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/44


From dsimms at openjdk.java.net  Thu May 14 06:46:37 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 14 May 2020 06:46:37 GMT
Subject: [lworld] [Rev 01] RFR: 8244810: [lworld] Decommission
 arrayStorageProperties from Klass:array_klass() et el
In-Reply-To: <sN9sCOJVnl4xs3XWj7irao04EYcYr6IAOhIVyRNDqJI=.11d64306-7d4f-4150-b1af-326307caf987@github.com>
References: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
 <tQF2FkKwpG2ITlAz3hccp8REq1SjTDenOc05Aw8Lny4=.3c04f1e2-578f-49c5-b420-d3ca824d5465@github.com>
 <sN9sCOJVnl4xs3XWj7irao04EYcYr6IAOhIVyRNDqJI=.11d64306-7d4f-4150-b1af-326307caf987@github.com>
Message-ID: <lagbryjCJjPXcTZPZhJy3sJRexdxOIi0FNJGnSpJq_0=.91f79cf3-e66e-4040-acfa-f318ba56ce6e@github.com>

On Wed, 13 May 2020 16:10:44 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> David Simms has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright syntax
>
> src/hotspot/share/oops/arrayStorageProperties.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> (Comment for the whole file)
> I understand this is the first stage of a set of complex changes to remove the `ArrayStorageProperties` code, but
> cleaning up the `ArrayStorageProperties` as things are getting removed might help to see progress (and would make
> reviews easier). For instance:
>   - `clear_flattened()`
>   - `set_flattened()`
>   - `set_null_free()`
>   - `for_signature(Symbol* sig)`
> seem to not be used anymore and could be removed.

Correct, ultimately the whole thing can go...but yes, they can go now.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/44


From dsimms at openjdk.java.net  Thu May 14 07:41:23 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 14 May 2020 07:41:23 GMT
Subject: [lworld] [Rev 02] RFR: 8244810: [lworld] Decommission
 arrayStorageProperties from Klass:array_klass() et el
In-Reply-To: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
References: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
Message-ID: <FREehML8ghU4MIJzW868YkIQ-_dFpRpn8fLnnydVk3Q=.3d57e9df-5e62-40c7-ae6b-d62cf8e4bcdc@github.com>

> First part of LW2 to LW3 arrays

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Applied Fred's comments

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/44/files
  - new: https://git.openjdk.java.net/valhalla/pull/44/files/ec8c49cc..f4e03940

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/44/webrev.02
 - incr: https://webrevs.openjdk.java.net/valhalla/44/webrev.01-02

  Stats: 14 lines in 3 files changed: 0 ins; 10 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/44.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/44/head:pull/44

PR: https://git.openjdk.java.net/valhalla/pull/44


From dsimms at openjdk.java.net  Thu May 14 07:41:45 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 14 May 2020 07:41:45 GMT
Subject: [Integrated] [lworld] RFR: 8244810: [lworld] Decommission
 arrayStorageProperties from Klass:array_klass() et el
In-Reply-To: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
References: <myKtofXlq6J87Pyap6l1JJzj4RZsdq-djwECGi9ZLJo=.688eef29-646d-435b-ad11-a40b631469c5@github.com>
Message-ID: <lXxUDJTkfY5almwpmLtIscqhbYhOzLQeu6CADyzB05Y=.1d2e3e55-9242-43f3-b2b0-3a86316807b7@github.com>

On Wed, 13 May 2020 08:56:01 GMT, David Simms <dsimms at openjdk.org> wrote:

> First part of LW2 to LW3 arrays

This pull request has now been integrated.

Changeset: 2e5a9581
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/2e5a9581
Stats:     220 lines in 26 files changed: 69 ins; 32 del; 119 mod

8244810: [lworld] Decommission arrayStorageProperties from Klass:array_klass() et el

-------------

PR: https://git.openjdk.java.net/valhalla/pull/44


From forax at univ-mlv.fr  Thu May 14 08:39:06 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 14 May 2020 10:39:06 +0200 (CEST)
Subject: [lworld] RFR: 8244796: [lworld] Javac does not compile
 test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
In-Reply-To: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
References: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
Message-ID: <470471236.183412.1589445546532.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Srikanth Adayapalam" <sadayapalam at openjdk.java.net>
> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Jeudi 14 Mai 2020 03:40:04
> Objet: [lworld] RFR: 8244796: [lworld] Javac does not compile
> test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore

> Summary: Implement temporary typing rules for value class literals, these being:
> 
>    o Given a value class V that implements an interface I
>        - Class<V>, Class<? extends V>, Class<? super V> are all malformed for the time
>        being.
>        - V.class and v.getClass() are to be typed temporarily as Class<? extends Object
>        & I>
> 

Hi Srikanth,
why V.class is not typed as Class<? extends V.ref> ?

R?mi

> -------------
> 
> Commit messages:
> - Additional fixes for typing of value class literals.
> - Merge branch 'JDK-8244796' of https://github.com/sadayapalam/valhalla into
> JDK-8244796
> - 8244796: Javac does not compile
> test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
> - 8244796: Javac does not compile
> test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
> 
> Changes: https://git.openjdk.java.net/valhalla/pull/46/files
> Webrev: https://webrevs.openjdk.java.net/valhalla/46/webrev.00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8244796
>  Stats: 91 lines in 6 files changed: 85 ins; 2 del; 4 mod
>  Patch: https://git.openjdk.java.net/valhalla/pull/46.diff
>  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/46/head:pull/46
> 
> PR: https://git.openjdk.java.net/valhalla/pull/46


From dsimms at openjdk.java.net  Thu May 14 08:40:55 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 14 May 2020 08:40:55 GMT
Subject: [Integrated] [lworld] FYI: 8244934: [lworld] Copyright header
 format
In-Reply-To: <5ZDQUurTuD7RYGWIJNnw-49KwaLpn0nvX_1VfXUxa1E=.cbd00e47-9f8e-4a7c-9861-8c30d8923036@github.com>
References: <5ZDQUurTuD7RYGWIJNnw-49KwaLpn0nvX_1VfXUxa1E=.cbd00e47-9f8e-4a7c-9861-8c30d8923036@github.com>
Message-ID: <PCrg4R_V1XGXDD1wDKbqL4bGRhLZfah8-2o3wudHxqI=.ff3519db-05b0-45d2-aa41-81ef8f73143e@github.com>

On Thu, 14 May 2020 08:31:09 GMT, David Simms <dsimms at openjdk.org> wrote:

> Some badly formatted files adjusted

This pull request has now been integrated.

Changeset: df9b1ac7
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/df9b1ac7
Stats:     35 lines in 17 files changed: 4 ins; 1 del; 30 mod

8244934: [lworld] Copyright header format

-------------

PR: https://git.openjdk.java.net/valhalla/pull/47


From dsimms at openjdk.java.net  Thu May 14 08:40:55 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 14 May 2020 08:40:55 GMT
Subject: [lworld] FYI: 8244934: [lworld] Copyright header format
Message-ID: <5ZDQUurTuD7RYGWIJNnw-49KwaLpn0nvX_1VfXUxa1E=.cbd00e47-9f8e-4a7c-9861-8c30d8923036@github.com>

Some badly formatted files adjusted

-------------

Commit messages:
 - 8244934: [lworld] Copyright header format

Changes: https://git.openjdk.java.net/valhalla/pull/47/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/47/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244934
  Stats: 35 lines in 17 files changed: 1 ins; 4 del; 30 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/47/head:pull/47

PR: https://git.openjdk.java.net/valhalla/pull/47


From srikanth.adayapalam at oracle.com  Thu May 14 08:52:56 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Thu, 14 May 2020 14:22:56 +0530
Subject: [lworld] RFR: 8244796: [lworld] Javac does not compile
 test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
In-Reply-To: <470471236.183412.1589445546532.JavaMail.zimbra@u-pem.fr>
References: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
 <470471236.183412.1589445546532.JavaMail.zimbra@u-pem.fr>
Message-ID: <156fab03-ea62-042e-790c-f3fbbcb4c646@oracle.com>



On 14/05/20 2:09 pm, Remi Forax wrote:
> ----- Mail original -----
>> De: "Srikanth Adayapalam" <sadayapalam at openjdk.java.net>
>> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoy?: Jeudi 14 Mai 2020 03:40:04
>> Objet: [lworld] RFR: 8244796: [lworld] Javac does not compile
>> test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
>> Summary: Implement temporary typing rules for value class literals, these being:
>>
>>     o Given a value class V that implements an interface I
>>         - Class<V>, Class<? extends V>, Class<? super V> are all malformed for the time
>>         being.
>>         - V.class and v.getClass() are to be typed temporarily as Class<? extends Object
>>         & I>
>>
> Hi Srikanth,
> why V.class is not typed as Class<? extends V.ref> ?

I would say the operative word is "temporary" - this fix is basically so 
we can make things malleable enough to compile code that we used to 
compile with the type system as it existed in LW2 - to buy us time so to 
speak - to evolve all the rules around bounds checking in the LW3 world 
where an inline type V is not a subtype of jlO.

As for that specific typing, in the language model V is not a subtype of 
V.ref and we haven't figured out all the nuances of how inline 
widening/narrowing conversions interact with bounds checking.

Srikanth
>
> R?mi
>
>> -------------
>>
>> Commit messages:
>> - Additional fixes for typing of value class literals.
>> - Merge branch 'JDK-8244796' of https://github.com/sadayapalam/valhalla into
>> JDK-8244796
>> - 8244796: Javac does not compile
>> test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
>> - 8244796: Javac does not compile
>> test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
>>
>> Changes: https://git.openjdk.java.net/valhalla/pull/46/files
>> Webrev: https://webrevs.openjdk.java.net/valhalla/46/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8244796
>>   Stats: 91 lines in 6 files changed: 85 ins; 2 del; 4 mod
>>   Patch: https://git.openjdk.java.net/valhalla/pull/46.diff
>>   Fetch: git fetch https://git.openjdk.java.net/valhalla pull/46/head:pull/46
>>
>> PR: https://git.openjdk.java.net/valhalla/pull/46



From jlaskey at openjdk.java.net  Thu May 14 12:06:54 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 14 May 2020 12:06:54 GMT
Subject: [lworld] RFR: 8244796: [lworld] Javac does not compile
 test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore
In-Reply-To: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
References: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
Message-ID: <V3-a9yubhRzNj0Tnzl9g5IND6V59J6BbsGtUMiR7F-E=.3703a1af-0421-47cb-b7ca-036d0ea93605@github.com>

On Thu, 14 May 2020 01:34:10 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Summary: Implement temporary typing rules for value class literals, these being:
> 
>     o Given a value class V that implements an interface I
>         - Class<V>, Class<? extends V>, Class<? super V> are all malformed for the time being.
>         - V.class and v.getClass() are to be typed temporarily as Class<? extends Object & I>

Marked as reviewed by jlaskey (no project role).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/46


From sadayapalam at openjdk.java.net  Thu May 14 12:58:42 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 14 May 2020 12:58:42 GMT
Subject: [Integrated] [lworld] RFR: 8244796: [lworld] Javac does not
 compile test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java
 anymore
In-Reply-To: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
References: <SutQIrqW1hOCPFmm_ii_qXWmtCvEDdB2xAF45xWYT3g=.25368326-563c-41ac-9da4-6df6592e780d@github.com>
Message-ID: <MRjXctSYvfdRLCDhJ8GaR0obJ9-etPCmhoaGJglU2NA=.0fc0b36a-baf8-4e07-9f50-303efcfc41da@github.com>

On Thu, 14 May 2020 01:34:10 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Summary: Implement temporary typing rules for value class literals, these being:
> 
>     o Given a value class V that implements an interface I
>         - Class<V>, Class<? extends V>, Class<? super V> are all malformed for the time being.
>         - V.class and v.getClass() are to be typed temporarily as Class<? extends Object & I>

This pull request has now been integrated.

Changeset: 122aa795
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/122aa795
Stats:     91 lines in 6 files changed: 2 ins; 85 del; 4 mod

8244796: [lworld] Javac does not compile test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java anymore

Reviewed-by: jlaskey

-------------

PR: https://git.openjdk.java.net/valhalla/pull/46


From david.holmes at oracle.com  Thu May 14 13:21:41 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 May 2020 23:21:41 +1000
Subject: [lworld] FYI: 8244934: [lworld] Copyright header format
In-Reply-To: <5ZDQUurTuD7RYGWIJNnw-49KwaLpn0nvX_1VfXUxa1E=.cbd00e47-9f8e-4a7c-9861-8c30d8923036@github.com>
References: <5ZDQUurTuD7RYGWIJNnw-49KwaLpn0nvX_1VfXUxa1E=.cbd00e47-9f8e-4a7c-9861-8c30d8923036@github.com>
Message-ID: <c0ad43b8-b91f-8bd8-69e4-cd29dad687ca@oracle.com>

Hi Mr Simms,

Good to fix missing commas etc but if all you are changing is the 
copyright notice then that doesn't result in an update to the copyright 
year.

Cheers,
David

On 14/05/2020 6:40 pm, David Simms wrote:
> Some badly formatted files adjusted
> 
> -------------
> 
> Commit messages:
>   - 8244934: [lworld] Copyright header format
> 
> Changes: https://git.openjdk.java.net/valhalla/pull/47/files
>   Webrev: https://webrevs.openjdk.java.net/valhalla/47/webrev.00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8244934
>    Stats: 35 lines in 17 files changed: 1 ins; 4 del; 30 mod
>    Patch: https://git.openjdk.java.net/valhalla/pull/47.diff
>    Fetch: git fetch https://git.openjdk.java.net/valhalla pull/47/head:pull/47
> 
> PR: https://git.openjdk.java.net/valhalla/pull/47
> 


From sadayapalam at openjdk.java.net  Fri May 15 05:14:36 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 15 May 2020 05:14:36 GMT
Subject: [lworld] RFR: 8244982: [lworld] Javac does not compile
 test/jdk/valhalla/valuetypes/StreamTest.java anymore
Message-ID: <XrXPyCyDA_YpcTOqqID3HjtaGqLfZL0-s3YXLhiDqq0=.1b1c9884-a4b3-45e6-84d2-05a210eb1390@github.com>

Jim, could you please review this fix ? Here is some background:

ATM, we infer (by design) Arrays.stream(X[]) to be a Stream<X.ref> (and not as
Stream<X\> as the latter is malformed as of now) and so the method reference X::data
ends up with a receiver type of X.ref instead of X.

Until such time JLS 15.13.1 (Compile-Time Declaration of a Method Reference) is
amended to account for inline widening/narrowing conversions, this is ilegal
code (as there is no subtyping relationship between X.ref and X) and to make it
work the test has to be changed to use X.ref::data instead of X::data

With this change, the test code would compile, but in order to be able to run it
we need a further tweak in LambdaToMethod. Since in the present code generation
scheme, X$ref.class files are completely empty, lambda meta factory would go looking
for a method data() in X$ref during bootstrap and this would result in a
NoSuchMethodError. To workaround that, we use a tried and tested trick in javac
land where we fold the method reference into a lambda and in the lambda body apply
suitable inline conversions.

So the method reference X.ref::data gets transformed into an equivalent lambda
       (Object rec$)->((X.ref)rec$).data()
in com.sun.tools.javac.comp.LambdaToMethod.MemberReferenceToLambda#lambda

This also has the "wrong" receiver, but we already have code in
com.sun.tools.javac.jvm.TransValues#visitSelect to sharpen the receiver and
make it ((X)(X.ref)rec$).data()

Finally, there also a change in TransValues that is not essential to this fix,
but is related. We were inadvertantly changing a local variable (only) without
really changing the AST (as we should). This is corrected now.

(If you are wondering how despite this things were working, that is because
com.sun.tools.javac.jvm.Gen#binaryQualifier was covering for us. It is not
incorrect to let com.sun.tools.javac.jvm.Gen#binaryQualifier handle it, but
is a waste of resource in that it creates an additional clone, while we
already have a clone handy)

-------------

Commit messages:
 - 8244982: Javac does not compile test/jdk/valhalla/valuetypes/StreamTest.java anymore

Changes: https://git.openjdk.java.net/valhalla/pull/48/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/48/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244982
  Stats: 85 lines in 4 files changed: 82 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/48/head:pull/48

PR: https://git.openjdk.java.net/valhalla/pull/48


From sadayapalam at openjdk.java.net  Fri May 15 05:57:46 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 15 May 2020 05:57:46 GMT
Subject: [lworld] FYI: 8244563: [lworld] Javac does not allow jlO to be
 express superclass of inline types.
Message-ID: <IahtHM_4PSpkIdJ4b2bSvyOKuydwLdzCgfws-w6MKus=.9abbdaef-edd6-4ecf-8d86-7d2637cb70c7@github.com>

Tolerate jlO as an express supertype of an inline class.

-------------

Commit messages:
 - 8244563:  Javac does not allow jlO to be express superclass of inline types

Changes: https://git.openjdk.java.net/valhalla/pull/49/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/49/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244563
  Stats: 11 lines in 6 files changed: 0 ins; 3 del; 8 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/49.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/49/head:pull/49

PR: https://git.openjdk.java.net/valhalla/pull/49


From sadayapalam at openjdk.java.net  Fri May 15 05:57:47 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 15 May 2020 05:57:47 GMT
Subject: [Integrated] [lworld] FYI: 8244563: [lworld] Javac does not allow
 jlO to be express superclass of inline types.
In-Reply-To: <IahtHM_4PSpkIdJ4b2bSvyOKuydwLdzCgfws-w6MKus=.9abbdaef-edd6-4ecf-8d86-7d2637cb70c7@github.com>
References: <IahtHM_4PSpkIdJ4b2bSvyOKuydwLdzCgfws-w6MKus=.9abbdaef-edd6-4ecf-8d86-7d2637cb70c7@github.com>
Message-ID: <5kZweTkGvzcDyPcUDNTNMR44bAE656MYWbvYTm0GN2Y=.17af1ca7-44d6-4995-8423-f3531b5d88ef@github.com>

On Fri, 15 May 2020 05:49:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Tolerate jlO as an express supertype of an inline class.

This pull request has now been integrated.

Changeset: c82e6b98
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c82e6b98
Stats:     11 lines in 6 files changed: 3 ins; 0 del; 8 mod

8244563: [lworld] Javac does not allow jlO to be express superclass of inline types.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/49


From sadayapalam at openjdk.java.net  Fri May 15 11:51:16 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 15 May 2020 11:51:16 GMT
Subject: [Integrated] [lworld] RFR: 8244982: [lworld] Javac does not
 compile test/jdk/valhalla/valuetypes/StreamTest.java anymore
In-Reply-To: <XrXPyCyDA_YpcTOqqID3HjtaGqLfZL0-s3YXLhiDqq0=.1b1c9884-a4b3-45e6-84d2-05a210eb1390@github.com>
References: <XrXPyCyDA_YpcTOqqID3HjtaGqLfZL0-s3YXLhiDqq0=.1b1c9884-a4b3-45e6-84d2-05a210eb1390@github.com>
Message-ID: <G4B0EIP4xu-Yt3dO-ZXp3LGaBBrk0he9ypXVKEo2w18=.8a6bd19e-2829-454d-866a-8c00d8532b62@github.com>

On Fri, 15 May 2020 05:06:46 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, could you please review this fix ? Here is some background:
> 
> ATM, we infer (by design) Arrays.stream(X[]) to be a Stream<X.ref> (and not as
> Stream<X\> as the latter is malformed as of now) and so the method reference X::data
> ends up with a receiver type of X.ref instead of X.
> 
> Until such time JLS 15.13.1 (Compile-Time Declaration of a Method Reference) is
> amended to account for inline widening/narrowing conversions, this is ilegal
> code (as there is no subtyping relationship between X.ref and X) and to make it
> work the test has to be changed to use X.ref::data instead of X::data
> 
> With this change, the test code would compile, but in order to be able to run it
> we need a further tweak in LambdaToMethod. Since in the present code generation
> scheme, X$ref.class files are completely empty, lambda meta factory would go looking
> for a method data() in X$ref during bootstrap and this would result in a
> NoSuchMethodError. To workaround that, we use a tried and tested trick in javac
> land where we fold the method reference into a lambda and in the lambda body apply
> suitable inline conversions.
> 
> So the method reference X.ref::data gets transformed into an equivalent lambda
>        (Object rec$)->((X.ref)rec$).data()
> in com.sun.tools.javac.comp.LambdaToMethod.MemberReferenceToLambda#lambda
> 
> This also has the "wrong" receiver, but we already have code in
> com.sun.tools.javac.jvm.TransValues#visitSelect to sharpen the receiver and
> make it ((X)(X.ref)rec$).data()
> 
> Finally, there also a change in TransValues that is not essential to this fix,
> but is related. We were inadvertantly changing a local variable (only) without
> really changing the AST (as we should). This is corrected now.
> 
> (If you are wondering how despite this things were working, that is because
> com.sun.tools.javac.jvm.Gen#binaryQualifier was covering for us. It is not
> incorrect to let com.sun.tools.javac.jvm.Gen#binaryQualifier handle it, but
> is a waste of resource in that it creates an additional clone, while we
> already have a clone handy)

This pull request has now been integrated.

Changeset: c6b21d17
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c6b21d17
Stats:     85 lines in 4 files changed: 0 ins; 82 del; 3 mod

8244982: lworld] Javac does not compile test/jdk/valhalla/valuetypes/StreamTest.java anymore

Reviewed-by: jlaskey

-------------

PR: https://git.openjdk.java.net/valhalla/pull/48


From jlaskey at openjdk.java.net  Fri May 15 11:51:15 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 15 May 2020 11:51:15 GMT
Subject: [lworld] RFR: 8244982: [lworld] Javac does not compile
 test/jdk/valhalla/valuetypes/StreamTest.java anymore
In-Reply-To: <XrXPyCyDA_YpcTOqqID3HjtaGqLfZL0-s3YXLhiDqq0=.1b1c9884-a4b3-45e6-84d2-05a210eb1390@github.com>
References: <XrXPyCyDA_YpcTOqqID3HjtaGqLfZL0-s3YXLhiDqq0=.1b1c9884-a4b3-45e6-84d2-05a210eb1390@github.com>
Message-ID: <0LepWvWbtT8yEpMST0Ncz6pFFnX7asmsscoihMTbl3I=.e4036062-25a7-4887-9f6d-16b3d8cb6f73@github.com>

On Fri, 15 May 2020 05:06:46 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, could you please review this fix ? Here is some background:
> 
> ATM, we infer (by design) Arrays.stream(X[]) to be a Stream<X.ref> (and not as
> Stream<X\> as the latter is malformed as of now) and so the method reference X::data
> ends up with a receiver type of X.ref instead of X.
> 
> Until such time JLS 15.13.1 (Compile-Time Declaration of a Method Reference) is
> amended to account for inline widening/narrowing conversions, this is ilegal
> code (as there is no subtyping relationship between X.ref and X) and to make it
> work the test has to be changed to use X.ref::data instead of X::data
> 
> With this change, the test code would compile, but in order to be able to run it
> we need a further tweak in LambdaToMethod. Since in the present code generation
> scheme, X$ref.class files are completely empty, lambda meta factory would go looking
> for a method data() in X$ref during bootstrap and this would result in a
> NoSuchMethodError. To workaround that, we use a tried and tested trick in javac
> land where we fold the method reference into a lambda and in the lambda body apply
> suitable inline conversions.
> 
> So the method reference X.ref::data gets transformed into an equivalent lambda
>        (Object rec$)->((X.ref)rec$).data()
> in com.sun.tools.javac.comp.LambdaToMethod.MemberReferenceToLambda#lambda
> 
> This also has the "wrong" receiver, but we already have code in
> com.sun.tools.javac.jvm.TransValues#visitSelect to sharpen the receiver and
> make it ((X)(X.ref)rec$).data()
> 
> Finally, there also a change in TransValues that is not essential to this fix,
> but is related. We were inadvertantly changing a local variable (only) without
> really changing the AST (as we should). This is corrected now.
> 
> (If you are wondering how despite this things were working, that is because
> com.sun.tools.javac.jvm.Gen#binaryQualifier was covering for us. It is not
> incorrect to let com.sun.tools.javac.jvm.Gen#binaryQualifier handle it, but
> is a waste of resource in that it creates an additional clone, while we
> already have a clone handy)

Thanks for the explanation. Looks good. Love it when punting still yields a good result.

-------------

Marked as reviewed by jlaskey (no project role).

PR: https://git.openjdk.java.net/valhalla/pull/48


From sadayapalam at openjdk.java.net  Mon May 18 12:20:20 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 18 May 2020 12:20:20 GMT
Subject: [lworld] RFR: 8242612: [lworld] Javac should not expressly encode the
 new super interface types in class files
Message-ID: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>

Jim, Could you please review this change ? TIA.

Changes:

    - Withdraw the new top type InlineObject (per design)
    - Do not encode the new top types in class files as this is noisy and
      very disruptive and let the static compiler and the dynamic environments
      inject these types as needed. (since classes compiled with legacy compilers
      will not encode these top types anyway the VM has to resort to injection,
      why not resort to injection for everything is the motivation)
    - Adjust some code that is surprised by super interfaces being empty.

More background is available in https://bugs.openjdk.java.net/browse/JDK-8242612

-------------

Commit messages:
 - 8242612: [lworld] Javac should not expressly encode the new super interface types in class files

Changes: https://git.openjdk.java.net/valhalla/pull/50/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/50/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242612
  Stats: 138 lines in 12 files changed: 24 ins; 101 del; 13 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/50.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/50/head:pull/50

PR: https://git.openjdk.java.net/valhalla/pull/50


From jlaskey at openjdk.java.net  Mon May 18 12:53:57 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 18 May 2020 12:53:57 GMT
Subject: [lworld] RFR: 8242612: [lworld] Javac should not expressly encode
 the new super interface types in class files
In-Reply-To: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>
References: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>
Message-ID: <BuBouzR5j6kiTNWTld47Xh81ovDjK0A0gZUbKeC9ASM=.6601a231-f674-4ca6-bec6-71361542db65@github.com>

On Mon, 18 May 2020 12:14:23 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Jim, Could you please review this change ? TIA.
> 
> Changes:
> 
>     - Withdraw the new top type InlineObject (per design)
>     - Do not encode the new top types in class files as this is noisy and
>       very disruptive and let the static compiler and the dynamic environments
>       inject these types as needed. (since classes compiled with legacy compilers
>       will not encode these top types anyway the VM has to resort to injection,
>       why not resort to injection for everything is the motivation)
>     - Adjust some code that is surprised by super interfaces being empty.
> 
> More background is available in https://bugs.openjdk.java.net/browse/JDK-8242612

Changes requested by jlaskey (no project role).

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 276:

> 275:                         Type it;
> 276:                         if (ct.interfaces_field == null || ct.interfaces_field.isEmpty()) {
> 277:                             it = objectType;

I'm assuming that you are using this to indicate no top interfaces. Is this safe (non-hackish)?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2526:

> 2525:                     ClassType ct = (ClassType) qualifierType;
> 2526:                     if (ct.interfaces_field == null || ct.interfaces_field.isEmpty()) {
> 2527:                         wcb = syms.objectType;

Same - maybe define a predicate for this.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/50


From sadayapalam at openjdk.java.net  Mon May 18 13:22:12 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 18 May 2020 13:22:12 GMT
Subject: [lworld] RFR: 8242612: [lworld] Javac should not expressly encode
 the new super interface types in class files
In-Reply-To: <BuBouzR5j6kiTNWTld47Xh81ovDjK0A0gZUbKeC9ASM=.6601a231-f674-4ca6-bec6-71361542db65@github.com>
References: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>
 <BuBouzR5j6kiTNWTld47Xh81ovDjK0A0gZUbKeC9ASM=.6601a231-f674-4ca6-bec6-71361542db65@github.com>
Message-ID: <lg2edLsByd7gLLQ0pAbAM5GEpQK7-1KiyFlUrrFT3tw=.9d1a2e8f-f195-4415-8e46-cc0b6c885e48@github.com>

On Mon, 18 May 2020 12:44:53 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Jim, Could you please review this change ? TIA.
>> 
>> Changes:
>> 
>>     - Withdraw the new top type InlineObject (per design)
>>     - Do not encode the new top types in class files as this is noisy and
>>       very disruptive and let the static compiler and the dynamic environments
>>       inject these types as needed. (since classes compiled with legacy compilers
>>       will not encode these top types anyway the VM has to resort to injection,
>>       why not resort to injection for everything is the motivation)
>>     - Adjust some code that is surprised by super interfaces being empty.
>> 
>> More background is available in https://bugs.openjdk.java.net/browse/JDK-8242612
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 276:
> 
>> 275:                         Type it;
>> 276:                         if (ct.interfaces_field == null || ct.interfaces_field.isEmpty()) {
>> 277:                             it = objectType;
> 
> I'm assuming that you are using this to indicate no top interfaces. Is this safe (non-hackish)?

Yes, it is safe. Basically earlier on all value classes had at least one interface (InlineObject) and possibly more.
Now the magic top type InlineObject going away, values may have no super interfaces at all and this would upset
makeIntersectionType which first asserts that it has not been called with an empty list of types.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/50


From sadayapalam at openjdk.java.net  Mon May 18 13:48:51 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 18 May 2020 13:48:51 GMT
Subject: [lworld] [Rev 01] RFR: 8242612: [lworld] Javac should not
 expressly encode the new super interface types in class files
In-Reply-To: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>
References: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>
Message-ID: <BMFqCwDcO47GLCIgm8ZaIinjypUMdpmaoOOfb9PDhbM=.c176bbc4-b455-49aa-a640-4fbc520cd9d9@github.com>

> Jim, Could you please review this change ? TIA.
> 
> Changes:
> 
>     - Withdraw the new top type InlineObject (per design)
>     - Do not encode the new top types in class files as this is noisy and
>       very disruptive and let the static compiler and the dynamic environments
>       inject these types as needed. (since classes compiled with legacy compilers
>       will not encode these top types anyway the VM has to resort to injection,
>       why not resort to injection for everything is the motivation)
>     - Adjust some code that is surprised by super interfaces being empty.
> 
> More background is available in https://bugs.openjdk.java.net/browse/JDK-8242612

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Simplify code per review comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/50/files
  - new: https://git.openjdk.java.net/valhalla/pull/50/files/94e232ee..ecb41ea4

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/50/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/50/webrev.00-01

  Stats: 14 lines in 2 files changed: 0 ins; 10 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/50.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/50/head:pull/50

PR: https://git.openjdk.java.net/valhalla/pull/50


From jlaskey at openjdk.java.net  Mon May 18 13:49:42 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 18 May 2020 13:49:42 GMT
Subject: [lworld] [Rev 01] RFR: 8242612: [lworld] Javac should not
 expressly encode the new super interface types in class files
In-Reply-To: <BMFqCwDcO47GLCIgm8ZaIinjypUMdpmaoOOfb9PDhbM=.c176bbc4-b455-49aa-a640-4fbc520cd9d9@github.com>
References: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>
 <BMFqCwDcO47GLCIgm8ZaIinjypUMdpmaoOOfb9PDhbM=.c176bbc4-b455-49aa-a640-4fbc520cd9d9@github.com>
Message-ID: <nEgCLGer3r0WEoxQe9pB3h0vYdMLm1KWfWJLUkLjDCQ=.ce36bfd9-8672-4d14-8124-9d148941c873@github.com>

On Mon, 18 May 2020 13:48:51 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Jim, Could you please review this change ? TIA.
>> 
>> Changes:
>> 
>>     - Withdraw the new top type InlineObject (per design)
>>     - Do not encode the new top types in class files as this is noisy and
>>       very disruptive and let the static compiler and the dynamic environments
>>       inject these types as needed. (since classes compiled with legacy compilers
>>       will not encode these top types anyway the VM has to resort to injection,
>>       why not resort to injection for everything is the motivation)
>>     - Adjust some code that is surprised by super interfaces being empty.
>> 
>> More background is available in https://bugs.openjdk.java.net/browse/JDK-8242612
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify code per review comments.

Marked as reviewed by jlaskey (no project role).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/50


From sadayapalam at openjdk.java.net  Mon May 18 15:47:09 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 18 May 2020 15:47:09 GMT
Subject: [lworld] [Rev 02] RFR: 8242612: [lworld] Javac should not
 expressly encode the new super interface types in class files
In-Reply-To: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>
References: <Tg1-X4jm8IBgPBb0BlWDAtwZnfggZklikn5f0pHZANs=.64c4b133-040e-4418-a1df-8602905c541a@github.com>
Message-ID: <R58Kyf4igc7DotJFx5FDlNO0YjWkPAkUZClk_JpWvi4=.8d41baab-54d9-4655-8a7c-cacf6f1db935@github.com>

> Jim, Could you please review this change ? TIA.
> 
> Changes:
> 
>     - Withdraw the new top type InlineObject (per design)
>     - Do not encode the new top types in class files as this is noisy and
>       very disruptive and let the static compiler and the dynamic environments
>       inject these types as needed. (since classes compiled with legacy compilers
>       will not encode these top types anyway the VM has to resort to injection,
>       why not resort to injection for everything is the motivation)
>     - Adjust some code that is surprised by super interfaces being empty.
> 
> More background is available in https://bugs.openjdk.java.net/browse/JDK-8242612

Srikanth Adayapalam has updated the pull request incrementally with two additional commits since the last revision:

 - Fix white space issue
 - Test changes for JDK-8242612, reverting changes made for explicit encoding of top types

This pull request has now been integrated.

Changeset: 9a5e8f39
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9a5e8f39
Stats:     279 lines in 75 files changed: 151 ins; 21 del; 107 mod

8242612: lworld] Javac should not expressly encode the new super interface types in class files
8237954: [lworld] @ignored tests need to be tweaked and reenabled.

Reviewed-by: jlaskey

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/50/files
  - new: https://git.openjdk.java.net/valhalla/pull/50/files/ecb41ea4..70002a64

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/50/webrev.02
 - incr: https://webrevs.openjdk.java.net/valhalla/50/webrev.01-02

  Stats: 152 lines in 63 files changed: 9 ins; 52 del; 91 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/50.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/50/head:pull/50

PR: https://git.openjdk.java.net/valhalla/pull/50


From fparain at openjdk.java.net  Mon May 18 20:39:24 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 18 May 2020 20:39:24 GMT
Subject: [lworld] RFR: 8245216: [lword] The JVM should inject the
 IdentityObject interface to types which need it
Message-ID: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>

Please review these changes for JDK-8245216.

This code makes the JVM to inject the IdentityObject interface when needed.
The details are in the CR:
https://bugs.openjdk.java.net/browse/JDK-8245216

Thank you,

Fred

-------------

Commit messages:
 - Fix tabs
 - Fix tabs and whitespaces
 - 8245216: [lword] The JVM should inject the IdentityObject interface to types which need it

Changes: https://git.openjdk.java.net/valhalla/pull/51/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/51/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245216
  Stats: 283 lines in 20 files changed: 244 ins; 11 del; 28 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/51/head:pull/51

PR: https://git.openjdk.java.net/valhalla/pull/51


From fparain at openjdk.java.net  Mon May 18 21:23:12 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 18 May 2020 21:23:12 GMT
Subject: [lworld] RFR: 8245216: [lword] The JVM should inject the
 IdentityObject interface to types which need it
In-Reply-To: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
Message-ID: <MVWT_2M8ivimhbGeuFfjDHlKnntVC-Jr1S0DSgwep_A=.97a6c75c-4f44-48fb-9238-e2882adb77c2@github.com>

On Mon, 18 May 2020 20:23:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes for JDK-8245216.
> 
> This code makes the JVM to inject the IdentityObject interface when needed.
> The details are in the CR:
> https://bugs.openjdk.java.net/browse/JDK-8245216
> 
> Thank you,
> 
> Fred

Got some crashes during testing, investigating...

-------------

PR: https://git.openjdk.java.net/valhalla/pull/51


From sadayapalam at openjdk.java.net  Tue May 19 02:55:55 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 19 May 2020 02:55:55 GMT
Subject: [lworld] RFR: 8245216: [lword] The JVM should inject the
 IdentityObject interface to types which need it
In-Reply-To: <MVWT_2M8ivimhbGeuFfjDHlKnntVC-Jr1S0DSgwep_A=.97a6c75c-4f44-48fb-9238-e2882adb77c2@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
 <MVWT_2M8ivimhbGeuFfjDHlKnntVC-Jr1S0DSgwep_A=.97a6c75c-4f44-48fb-9238-e2882adb77c2@github.com>
Message-ID: <jqsxqgQn19lu0aW0WLqDZwCh1zJFIplBi6eJfr_d-3Q=.6c54f79b-8662-41b4-a3a5-967ad6e252b3@github.com>

On Mon, 18 May 2020 21:21:00 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review these changes for JDK-8245216.
>> 
>> This code makes the JVM to inject the IdentityObject interface when needed.
>> The details are in the CR:
>> https://bugs.openjdk.java.net/browse/JDK-8245216
>> 
>> Thank you,
>> 
>> Fred
>
> Got some crashes during testing, investigating...
> [update] Class instrumentation/redefinition requires some fixes.

This patch addresses the two langtools failure it should. Thanks!

However, hotspot/jtreg/runtime/valhalla/valuetypes/testSupers/TestSuperClasses.java is still referencing withdrawn
classes and fails. Are you able to include a fix for that too ?

I looked into preparing a patch, but not familiar with jcod files...

-------------

PR: https://git.openjdk.java.net/valhalla/pull/51


From fparain at openjdk.java.net  Tue May 19 15:32:14 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 19 May 2020 15:32:14 GMT
Subject: [lworld] RFR: 8245216: [lword] The JVM should inject the
 IdentityObject interface to types which need it
In-Reply-To: <jqsxqgQn19lu0aW0WLqDZwCh1zJFIplBi6eJfr_d-3Q=.6c54f79b-8662-41b4-a3a5-967ad6e252b3@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
 <MVWT_2M8ivimhbGeuFfjDHlKnntVC-Jr1S0DSgwep_A=.97a6c75c-4f44-48fb-9238-e2882adb77c2@github.com>
 <jqsxqgQn19lu0aW0WLqDZwCh1zJFIplBi6eJfr_d-3Q=.6c54f79b-8662-41b4-a3a5-967ad6e252b3@github.com>
Message-ID: <65GBkLW2j70inBn5jKl6_N7FQ8QigjTB0geB9fY1xk4=.a88876f5-0f07-4952-ac52-adc24b188b47@github.com>

On Tue, 19 May 2020 02:53:39 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Got some crashes during testing, investigating...
>> [update] Class instrumentation/redefinition requires some fixes.
>
> This patch addresses the two langtools failure it should. Thanks!
> 
> However, hotspot/jtreg/runtime/valhalla/valuetypes/testSupers/TestSuperClasses.java is still referencing withdrawn
> classes and fails. Are you able to include a fix for that too ?
> I looked into preparing a patch, but not familiar with jcod files...

The PR has been updated with the following changes:
  - fix JVMTI class file reconstruction to exclude injected interfaces
  - fix java.lang.Class.ArrayMethods and TestSuperClasses tests
  - fix JVMCI implementation and test

No more regression with tier1. Testing with tier2 and tier are in progress.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/51


From fparain at openjdk.java.net  Tue May 19 15:32:13 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 19 May 2020 15:32:13 GMT
Subject: [lworld] [Rev 01] RFR: 8245216: [lword] The JVM should inject the
 IdentityObject interface to types which need it
In-Reply-To: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
Message-ID: <1-oJJ-u_WKK2fFx6uhhpMHajBD3LZCORoJASt_duGak=.a1fbc2ae-912f-423e-946f-751d063bfedc@github.com>

> Please review these changes for JDK-8245216.
> 
> This code makes the JVM to inject the IdentityObject interface when needed.
> The details are in the CR:
> https://bugs.openjdk.java.net/browse/JDK-8245216
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with two additional commits since the last revision:

 - Fix tests and JVMCI
 - Exclude injected interfaces during class reconstitution

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/51/files
  - new: https://git.openjdk.java.net/valhalla/pull/51/files/1f8d4bbb..521561c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/51/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/51/webrev.00-01

  Stats: 46 lines in 6 files changed: 16 ins; 8 del; 22 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/51/head:pull/51

PR: https://git.openjdk.java.net/valhalla/pull/51


From fparain at openjdk.java.net  Tue May 19 21:39:55 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 19 May 2020 21:39:55 GMT
Subject: [lworld] RFR: 8245216: [lworld] The JVM should inject the
 IdentityObject interface to types which need it
In-Reply-To: <65GBkLW2j70inBn5jKl6_N7FQ8QigjTB0geB9fY1xk4=.a88876f5-0f07-4952-ac52-adc24b188b47@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
 <MVWT_2M8ivimhbGeuFfjDHlKnntVC-Jr1S0DSgwep_A=.97a6c75c-4f44-48fb-9238-e2882adb77c2@github.com>
 <jqsxqgQn19lu0aW0WLqDZwCh1zJFIplBi6eJfr_d-3Q=.6c54f79b-8662-41b4-a3a5-967ad6e252b3@github.com>
 <65GBkLW2j70inBn5jKl6_N7FQ8QigjTB0geB9fY1xk4=.a88876f5-0f07-4952-ac52-adc24b188b47@github.com>
Message-ID: <ALmwADo7-J8pBewe8tTZPcCFkykpa_n6d-hsMfgBQkM=.2c582d68-0e4a-4edb-aef3-183c7d529bce@github.com>

On Tue, 19 May 2020 15:24:10 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch addresses the two langtools failure it should. Thanks!
>> 
>> However, hotspot/jtreg/runtime/valhalla/valuetypes/testSupers/TestSuperClasses.java is still referencing withdrawn
>> classes and fails. Are you able to include a fix for that too ?
>> I looked into preparing a patch, but not familiar with jcod files...
>
> The PR has been updated with the following changes:
>   - fix JVMTI class file reconstruction to exclude injected interfaces
>   - fix java.lang.Class.ArrayMethods and TestSuperClasses tests
>   - fix JVMCI implementation and test
> 
> No more regression with tier1. Testing with tier2 and tier3 is in progress.

Stress testing shown an issue with metaspace allocation/deallocation.
Withdrawing the PR until the issue has been solved.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/51


From thartmann at openjdk.java.net  Wed May 20 11:24:55 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 20 May 2020 11:24:55 GMT
Subject: [lworld] FYI: 8245019: [lworld] SIGSEGV in BufferBlob::buffered value
 type due to instruction memory corruption
Message-ID: <jDd-ubzZmVxoYlB2Bm4EB2E_gPFB2c5Lon-KQUNL8DM=.d8d828c0-4d8d-4d48-9e36-f3b5e05991ba@github.com>

The layout of BufferedValueTypeBlob is incorrectly computed (sizeof(BufferBlob) instead of
sizeof(BufferedValueTypeBlob)) and as a result, the instructions at the start of the blob are overwritten by the C++
object header. This only happens with a product build, I assume with a debug build there is some additional padding.

-------------

Commit messages:
 - 8245019:[lworld] SIGSEGV in BufferBlob::buffered value type due to instruction memory corruption

Changes: https://git.openjdk.java.net/valhalla/pull/52/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/52/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245019
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/52/head:pull/52

PR: https://git.openjdk.java.net/valhalla/pull/52


From thartmann at openjdk.java.net  Wed May 20 11:24:55 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 20 May 2020 11:24:55 GMT
Subject: [Integrated] [lworld] FYI: 8245019: [lworld] SIGSEGV in
 BufferBlob::buffered value type due to instruction memory corruption
In-Reply-To: <jDd-ubzZmVxoYlB2Bm4EB2E_gPFB2c5Lon-KQUNL8DM=.d8d828c0-4d8d-4d48-9e36-f3b5e05991ba@github.com>
References: <jDd-ubzZmVxoYlB2Bm4EB2E_gPFB2c5Lon-KQUNL8DM=.d8d828c0-4d8d-4d48-9e36-f3b5e05991ba@github.com>
Message-ID: <9YVuasYAq_FwVGU6HtuWm0FqRjA7J74TeiY8yogxIfE=.cb7f87a6-8611-40fc-891d-d9bd7e8fa3bf@github.com>

On Wed, 20 May 2020 11:17:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The layout of BufferedValueTypeBlob is incorrectly computed (sizeof(BufferBlob) instead of
> sizeof(BufferedValueTypeBlob)) and as a result, the instructions at the start of the blob are overwritten by the C++
> object header. This only happens with a product build, I assume with a debug build there is some additional padding.

This pull request has now been integrated.

Changeset: e8894bd7
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e8894bd7
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8245019: lworld] SIGSEGV in BufferBlob::buffered value type due to instruction memory corruption

-------------

PR: https://git.openjdk.java.net/valhalla/pull/52


From fparain at openjdk.java.net  Wed May 20 15:36:37 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 20 May 2020 15:36:37 GMT
Subject: [lworld] [Rev 02] RFR: 8245216: [lworld] The JVM should inject
 the IdentityObject interface to types which need it
In-Reply-To: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
Message-ID: <OKNrNacRemgJ3Dmue2-2dnfCLVsnoxlqD0YAlD1xGoY=.a3dfab9b-d8fb-40ee-809c-ca72a9adad41@github.com>

> Please review these changes for JDK-8245216.
> 
> This code makes the JVM to inject the IdentityObject interface when needed.
> The details are in the CR:
> https://bugs.openjdk.java.net/browse/JDK-8245216
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup, bug fixes, work around for 8245487

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/51/files
  - new: https://git.openjdk.java.net/valhalla/pull/51/files/521561c0..00cfcb6c

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/51/webrev.02
 - incr: https://webrevs.openjdk.java.net/valhalla/51/webrev.01-02

  Stats: 13 lines in 2 files changed: 5 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/51/head:pull/51

PR: https://git.openjdk.java.net/valhalla/pull/51


From hseigel at openjdk.java.net  Wed May 20 17:39:58 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 20 May 2020 17:39:58 GMT
Subject: [lworld] [Rev 02] RFR: 8245216: [lworld] The JVM should inject
 the IdentityObject interface to types which need it
In-Reply-To: <OKNrNacRemgJ3Dmue2-2dnfCLVsnoxlqD0YAlD1xGoY=.a3dfab9b-d8fb-40ee-809c-ca72a9adad41@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
 <OKNrNacRemgJ3Dmue2-2dnfCLVsnoxlqD0YAlD1xGoY=.a3dfab9b-d8fb-40ee-809c-ca72a9adad41@github.com>
Message-ID: <M8Wr8yoL75l6l48j8CJR1TQLYS2UNjNpaiLkBg3Dxa8=.419d3c35-1443-4250-b73a-161425bd272c@github.com>

On Wed, 20 May 2020 15:36:37 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review these changes for JDK-8245216.
>> 
>> This code makes the JVM to inject the IdentityObject interface when needed.
>> The details are in the CR:
>> https://bugs.openjdk.java.net/browse/JDK-8245216
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup, bug fixes, work around for 8245487

Changes look good, other than the nit about the comment in verificationType.cpp.
Thanks for doing this.

src/hotspot/share/classfile/verificationType.cpp line 66:

> 65:     return !from_is_array ||
> 66:       this_class == SystemDictionary::Cloneable_klass() ||
> 67:       this_class == SystemDictionary::Serializable_klass() ||

Can you update the comment at line 63 to include java.lang.IdentityObject?

-------------

Marked as reviewed by hseigel (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/51


From fparain at openjdk.java.net  Wed May 20 21:37:09 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 20 May 2020 21:37:09 GMT
Subject: [lworld] [Rev 03] RFR: 8245216: [lworld] The JVM should inject
 the IdentityObject interface to types which need it
In-Reply-To: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
Message-ID: <QmOgSaKtxbtMZyYRab4C5qz2Ohbyef8DSBljATHOIxk=.849db2cc-9aa8-48f1-b464-55569b6d6739@github.com>

> Please review these changes for JDK-8245216.
> 
> This code makes the JVM to inject the IdentityObject interface when needed.
> The details are in the CR:
> https://bugs.openjdk.java.net/browse/JDK-8245216
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Mote test fixes, comment fix

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/51/files
  - new: https://git.openjdk.java.net/valhalla/pull/51/files/00cfcb6c..53a29d10

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/51/webrev.03
 - incr: https://webrevs.openjdk.java.net/valhalla/51/webrev.02-03

  Stats: 26 lines in 3 files changed: 14 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/51/head:pull/51

PR: https://git.openjdk.java.net/valhalla/pull/51


From fparain at openjdk.java.net  Wed May 20 21:37:09 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 20 May 2020 21:37:09 GMT
Subject: [lworld] [Rev 02] RFR: 8245216: [lworld] The JVM should inject
 the IdentityObject interface to types which need it
In-Reply-To: <M8Wr8yoL75l6l48j8CJR1TQLYS2UNjNpaiLkBg3Dxa8=.419d3c35-1443-4250-b73a-161425bd272c@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
 <OKNrNacRemgJ3Dmue2-2dnfCLVsnoxlqD0YAlD1xGoY=.a3dfab9b-d8fb-40ee-809c-ca72a9adad41@github.com>
 <M8Wr8yoL75l6l48j8CJR1TQLYS2UNjNpaiLkBg3Dxa8=.419d3c35-1443-4250-b73a-161425bd272c@github.com>
Message-ID: <TBu9nh01bhB1ttXc0T-idBi-PsQezlTvBOYwbITdFto=.623a16c4-9b71-4508-8664-c8a8a9b100e2@github.com>

On Wed, 20 May 2020 17:37:35 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup, bug fixes, work around for 8245487
>
> Changes look good, other than the nit about the comment in verificationType.cpp.
> Thanks for doing this.

Thank you Harold. I've updated the comment in verificationType.cpp in the last commit.

Fred

-------------

PR: https://git.openjdk.java.net/valhalla/pull/51


From fparain at openjdk.java.net  Thu May 21 12:13:37 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 21 May 2020 12:13:37 GMT
Subject: [lworld] [Rev 04] RFR: 8245216: [lworld] The JVM should inject
 the IdentityObject interface to types which need it
In-Reply-To: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
Message-ID: <FPscJQ3scG8XXsOzMyFRSO4S2SQadOLQPM8VoxbEe1M=.7aeeb843-6411-4f6e-9bc2-fbeaf86d222c@github.com>

> Please review these changes for JDK-8245216.
> 
> This code makes the JVM to inject the IdentityObject interface when needed.
> The details are in the CR:
> https://bugs.openjdk.java.net/browse/JDK-8245216
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Fix test comment

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/51/files
  - new: https://git.openjdk.java.net/valhalla/pull/51/files/53a29d10..ca70fca4

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/51/webrev.04
 - incr: https://webrevs.openjdk.java.net/valhalla/51/webrev.03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/51/head:pull/51

PR: https://git.openjdk.java.net/valhalla/pull/51


From fparain at openjdk.java.net  Thu May 21 12:44:02 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 21 May 2020 12:44:02 GMT
Subject: [Integrated] [lworld] RFR: 8245216: [lworld] The JVM should
 inject the IdentityObject interface to types which need it
In-Reply-To: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
References: <PhGrs27WJv2I0rapZedZkcae5xj89tPUDauONlQf_Js=.d29bfea2-c575-4043-9fe9-cee3b89cfc04@github.com>
Message-ID: <oWdfDsypH0FDnt25yNQPVcd-d86Jvt3gU72vNZoLMxo=.6d534f2b-bdb8-4c21-96ec-5100391306b0@github.com>

On Mon, 18 May 2020 20:23:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes for JDK-8245216.
> 
> This code makes the JVM to inject the IdentityObject interface when needed.
> The details are in the CR:
> https://bugs.openjdk.java.net/browse/JDK-8245216
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: ec75333c
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ec75333c
Stats:     365 lines in 28 files changed: 20 ins; 281 del; 64 mod

8245216: lworld] The JVM should inject the IdentityObject interface to types which need it

Reviewed-by: hseigel

-------------

PR: https://git.openjdk.java.net/valhalla/pull/51


From mchung at openjdk.java.net  Thu May 21 22:15:59 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 21 May 2020 22:15:59 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
Message-ID: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>

This patch updates the core reflection for the new language model for inline classes.

- `Class::isInlineClass` returns true for inline classes
- `Class::valueType` returns the value projection of an inline class
- `Class::referenceType` returns the reference projection if it's an inline class,
    or this class if it's not an inline class

If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
where  we can rather than holding to the tradition.

I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
and `Class:asIndirectType` is removed.

-------------

Commit messages:
 - Class::valueType and Class::referenceType return Optional
 - 8245584: [lworld] LW3 core reflection update

Changes: https://git.openjdk.java.net/valhalla/pull/53/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/53/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245584
  Stats: 545 lines in 40 files changed: 44 ins; 238 del; 263 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/53.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/53/head:pull/53

PR: https://git.openjdk.java.net/valhalla/pull/53


From rriggs at openjdk.java.net  Fri May 22 13:16:16 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 22 May 2020 13:16:16 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
Message-ID: <GWyQNAhWWQ8ITEk3S-FzWL1sMSvBs9mLIEqkDjOuExU=.e0574589-195b-44d1-ad51-e638e53fb1de@github.com>

On Thu, 21 May 2020 22:09:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This patch updates the core reflection for the new language model for inline classes.
> 
> - `Class::isInlineClass` returns true for inline classes
> - `Class::valueType` returns the value projection of an inline class
> - `Class::referenceType` returns the reference projection if it's an inline class,
>     or this class if it's not an inline class
> 
> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
> where  we can rather than holding to the tradition.
> 
> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
> and `Class:asIndirectType` is removed.

src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java line 674:

> 673:             } else {
> 674:                 stringBuilder.append('L');
> 675:             }

This could be:
`stringBuilder.append(IsInlineClass(currentClass) ? 'Q' : 'L');`

There may be a usefor a utility function that  returns Q or L as appropriate, it appears a few time.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From mchung at openjdk.java.net  Fri May 22 16:48:48 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 22 May 2020 16:48:48 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <GWyQNAhWWQ8ITEk3S-FzWL1sMSvBs9mLIEqkDjOuExU=.e0574589-195b-44d1-ad51-e638e53fb1de@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <GWyQNAhWWQ8ITEk3S-FzWL1sMSvBs9mLIEqkDjOuExU=.e0574589-195b-44d1-ad51-e638e53fb1de@github.com>
Message-ID: <kMEUErmuUyb7zFUYrXPl6XpB1LtdE-wPIr3bgowFiok=.818a3419-f0ae-4a7a-8ef1-0d148e26b006@github.com>

On Fri, 22 May 2020 13:12:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This patch updates the core reflection for the new language model for inline classes.
>> 
>> - `Class::isInlineClass` returns true for inline classes
>> - `Class::valueType` returns the value projection of an inline class
>> - `Class::referenceType` returns the reference projection if it's an inline class,
>>     or this class if it's not an inline class
>> 
>> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
>> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
>> where  we can rather than holding to the tradition.
>> 
>> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
>> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
>> and `Class:asIndirectType` is removed.
>
> src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java line 674:
> 
>> 673:             } else {
>> 674:                 stringBuilder.append('L');
>> 675:             }
> 
> This could be:
> `stringBuilder.append(IsInlineClass(currentClass) ? 'Q' : 'L');`
> 
> There may be a usefor a utility function that  returns Q or L as appropriate, it appears a few time.

`Class::descriptorString` should be used for the cases when it has a `Class` object.

`ProxyGenerator` and `AccessorGenerator` should be updated to use `Class::descriptorString` and `TypeDescriptor` API
where it's appropriate.  I suggest to update these classes in jdk/jdk.  I will file a JBS issue to track this.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From fparain at openjdk.java.net  Fri May 22 19:56:04 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 22 May 2020 19:56:04 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
Message-ID: <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>

On Thu, 21 May 2020 22:09:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This patch updates the core reflection for the new language model for inline classes.
> 
> - `Class::isInlineClass` returns true for inline classes
> - `Class::valueType` returns the value projection of an inline class
> - `Class::referenceType` returns the reference projection if it's an inline class,
>     or this class if it's not an inline class
> 
> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
> where  we can rather than holding to the tradition.
> 
> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
> and `Class:asIndirectType` is removed.

Hi Mandy,

The HotSpot changes look good in general, with a lot of nice cleanups.
You'll find two comments, one minor about hard-coded characters, and a second more significant about the
`Class::refType` field, for which you might want a review from the compiler team.

I find it disturbing to have VM code depending on value projection/reference projection fields when these are language
concepts that are not part of the VM model. but this has nothing to do with your changes, it might be due to the model
transition, or something we missed in the VM model.

Thank you,

Fred

src/hotspot/share/oops/instanceKlass.cpp line 2775:

> 2774:   int dest_index = 0;
> 2775:   dest[dest_index++] = is_value() ? 'Q' : 'L';
> 2776:

Should use `JVM_SIGNATURE_CLASS` and `JVM_SIGNATURE_VALUETYPE` instead of hard-coded characters.

src/hotspot/share/classfile/javaClasses.cpp line 1023:

> 1022:         set_ref_type_mirror(ref_type_oop, ref_type_oop);
> 1023:       }
> 1024:     }

With this code, if the super type of the inline type is `j.l.Object`, `Class:refType` will remain `null`. I'm not sure
that the VM code is ready to handle this situation. The only use case I've found is in
`LibraryCallKit::inline_value_Class_conversion(vmIntrinsics::ID id)` and I'm not familiar with it (the compiler team
might want to take a look at it).

-------------

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/53


From mchung at openjdk.java.net  Fri May 22 20:10:29 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 22 May 2020 20:10:29 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
Message-ID: <35UCqxaZ3EcflYgPfGGDeH30m5sF-TErf7cwpAuV8yk=.14ae9f4c-9850-40c3-96b3-4682fecfb07b@github.com>

On Fri, 22 May 2020 19:24:16 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch updates the core reflection for the new language model for inline classes.
>> 
>> - `Class::isInlineClass` returns true for inline classes
>> - `Class::valueType` returns the value projection of an inline class
>> - `Class::referenceType` returns the reference projection if it's an inline class,
>>     or this class if it's not an inline class
>> 
>> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
>> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
>> where  we can rather than holding to the tradition.
>> 
>> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
>> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
>> and `Class:asIndirectType` is removed.
>
> src/hotspot/share/oops/instanceKlass.cpp line 2775:
> 
>> 2774:   int dest_index = 0;
>> 2775:   dest[dest_index++] = is_value() ? 'Q' : 'L';
>> 2776:
> 
> Should use `JVM_SIGNATURE_CLASS` and `JVM_SIGNATURE_VALUETYPE` instead of hard-coded characters.

OK.  Will change this before I integrate.
diff --git a/src/hotspot/share/oops/instanceKlass.cpp b/src/hotspot/share/oops/instanceKlass.cpp
index c9b05990f41..b34421d7ccf 100644
--- a/src/hotspot/share/oops/instanceKlass.cpp
+++ b/src/hotspot/share/oops/instanceKlass.cpp
@@ -2772,7 +2772,7 @@ const char* InstanceKlass::signature_name() const {
 
   // Add L or Q as type indicator
   int dest_index = 0;
-  dest[dest_index++] = is_value() ? 'Q' : 'L';
+  dest[dest_index++] = is_value() ? JVM_SIGNATURE_VALUETYPE : JVM_SIGNATURE_CLASS;
 
   // Add the actual class name
   for (int src_index = 0; src_index < src_length; ) {

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From mchung at openjdk.java.net  Fri May 22 20:10:29 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 22 May 2020 20:10:29 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <kMEUErmuUyb7zFUYrXPl6XpB1LtdE-wPIr3bgowFiok=.818a3419-f0ae-4a7a-8ef1-0d148e26b006@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <GWyQNAhWWQ8ITEk3S-FzWL1sMSvBs9mLIEqkDjOuExU=.e0574589-195b-44d1-ad51-e638e53fb1de@github.com>
 <kMEUErmuUyb7zFUYrXPl6XpB1LtdE-wPIr3bgowFiok=.818a3419-f0ae-4a7a-8ef1-0d148e26b006@github.com>
Message-ID: <3DSY4MpjY0-NQ6SEvORrZW1g2gstZvaNnwnKZSqqwKQ=.c2bff774-ad19-48c7-b5d7-0eb652ce862d@github.com>

On Fri, 22 May 2020 16:46:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java line 674:
>> 
>>> 673:             } else {
>>> 674:                 stringBuilder.append('L');
>>> 675:             }
>> 
>> This could be:
>> `stringBuilder.append(IsInlineClass(currentClass) ? 'Q' : 'L');`
>> 
>> There may be a usefor a utility function that  returns Q or L as appropriate, it appears a few time.
>
> `Class::descriptorString` should be used for the cases when it has a `Class` object.
> 
> `ProxyGenerator` and `AccessorGenerator` should be updated to use `Class::descriptorString` and `TypeDescriptor` API
> where it's appropriate.  I suggest to update these classes in jdk/jdk.  I will file a JBS issue to track this.

updated per your suggestion.

diff --git a/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java
b/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java index 680e764fb4c..b03c201e23e 100644
--- a/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java
+++ b/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java
@@ -667,12 +667,8 @@ public final class Type {
             }
             stringBuilder.append(descriptor);
         } else {
+            stringBuilder.append(isInlineClass(currentClass) ? 'Q' : 'L');
             String name = currentClass.getName();
-            if (isInlineClass(currentClass)) {
-                stringBuilder.append('Q');
-            } else {
-                stringBuilder.append('L');
-            }
             int nameLength = name.length();
             for (int i = 0; i < nameLength; ++i) {
                 char car = name.charAt(i);

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From mchung at openjdk.java.net  Fri May 22 20:12:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 22 May 2020 20:12:56 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
Message-ID: <1Iod3fdCWBIV1jLgKJN9cM8qjxpdI1lq6VFuVXve5vc=.b60ba60a-0ad8-4047-9889-e93494624a1b@github.com>

On Fri, 22 May 2020 19:39:36 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch updates the core reflection for the new language model for inline classes.
>> 
>> - `Class::isInlineClass` returns true for inline classes
>> - `Class::valueType` returns the value projection of an inline class
>> - `Class::referenceType` returns the reference projection if it's an inline class,
>>     or this class if it's not an inline class
>> 
>> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
>> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
>> where  we can rather than holding to the tradition.
>> 
>> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
>> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
>> and `Class:asIndirectType` is removed.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1023:
> 
>> 1022:         set_ref_type_mirror(ref_type_oop, ref_type_oop);
>> 1023:       }
>> 1024:     }
> 
> With this code, if the super type of the inline type is `j.l.Object`, `Class:refType` will remain `null`. I'm not sure
> that the VM code is ready to handle this situation. The only use case I've found is in
> `LibraryCallKit::inline_value_Class_conversion(vmIntrinsics::ID id)` and I'm not familiar with it (the compiler team
> might want to take a look at it).

The current compiler implementation is left from LW2.  It needs update for the new language model and I suspect it does
not depend on the ref type.

Are you okay if I integrate this change now and follow up with the compiler team separately?

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From jrose at openjdk.java.net  Sat May 23 18:51:14 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Sat, 23 May 2020 18:51:14 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
Message-ID: <cepdYZlN4b_vlv1Ym2q79WYcEcWc_N_IKhRyqBjuXyE=.ba5e9441-78db-4a5e-a827-b8f944634036@github.com>

On Fri, 22 May 2020 19:47:33 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch updates the core reflection for the new language model for inline classes.
>> 
>> - `Class::isInlineClass` returns true for inline classes
>> - `Class::valueType` returns the value projection of an inline class
>> - `Class::referenceType` returns the reference projection if it's an inline class,
>>     or this class if it's not an inline class
>> 
>> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
>> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
>> where  we can rather than holding to the tradition.
>> 
>> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
>> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
>> and `Class:asIndirectType` is removed.
>
> Hi Mandy,
> 
> The HotSpot changes look good in general, with a lot of nice cleanups.
> You'll find two comments, one minor about hard-coded characters, and a second more significant about the
> `Class::refType` field, for which you might want a review from the compiler team.
> I find it disturbing to have VM code depending on value projection/reference projection fields when these are language
> concepts that are not part of the VM model. but this has nothing to do with your changes, it might be due to the model
> transition, or something we missed in the VM model.  Thank you,
> 
> Fred

It's up to the source compiler to issue or not issue a V.ref class file.  Perhaps the user has manually created one, or
perhaps it is automatically generated, or perhaps the inline type is a HC and therefore cannot have been sealed to a
companion type.

The JVM has to take what's there and surface it; if it's not there the JVM has to carry on.  Since the core reflection
APIs are mostly about what's in the classfile, they don't try to reconstruct what the source language was, but rather
report any and all classfiles present.

But we do want to reflect the relation between V.ref and V.val, if both exist and are properly marked.  We need a
clearly stated rule for what "properly marked" means, and those rules are not nailed down yet, since we are hammering
out a story where V.ref might be either an interface or an abstract class.

I suggest that the final form of the reflection code for V.ref/V.val should be written in Java, and clearly and simply
implement whatever agreement we make in the end. Java code should manage the refType and valType fields, if possible.
Bootstrapping issues may force them to be managed by the JVM, as in this patch, but even in that case the code should
be set apart (probably as a subroutine or two) and documented clearly as relating to the above-mentioned agreement.

One comment, really for the future, regarding the shape of the Java API here:  It uses Optional and omits the "get"
prefix on accessors.  This is the New Style, as opposed to the Classic Style using null (for "empty" results) and a
"get" prefix ("getComponentType") to get a related type.  We may choose to to use the New Style for new reflection API
points, and if so let's not choose N different New Styles, but one New Style.  Personally I like removing "get"; I
accept Optional instead of null; and I also suggest that arrays (if any) be replaced by (immutable) Lists in the New
Style.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From dsimms at openjdk.java.net  Mon May 25 13:21:54 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 25 May 2020 13:21:54 GMT
Subject: [lworld] RFR: 8244931: [lworld] Decommission arrayStorageProperties
 from runtime null free and flat array tests
Message-ID: <3G9dEVHs5rPz51eC56wQnZ0r_55XfLXefaVTZ__iXrU=.e5e13781-c230-41a7-b0a8-5c54d752872b@github.com>

Moved runtime and interpreter flat & null free tests to klass layout helper

-------------

Commit messages:
 - 8244931: [lworld] Decommission arrayStorageProperties from runtime null free and flat array tests

Changes: https://git.openjdk.java.net/valhalla/pull/54/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/54/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244931
  Stats: 80 lines in 9 files changed: 51 ins; 4 del; 25 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/54.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/54/head:pull/54

PR: https://git.openjdk.java.net/valhalla/pull/54


From thartmann at openjdk.java.net  Mon May 25 14:04:22 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 25 May 2020 14:04:22 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <1Iod3fdCWBIV1jLgKJN9cM8qjxpdI1lq6VFuVXve5vc=.b60ba60a-0ad8-4047-9889-e93494624a1b@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
 <1Iod3fdCWBIV1jLgKJN9cM8qjxpdI1lq6VFuVXve5vc=.b60ba60a-0ad8-4047-9889-e93494624a1b@github.com>
Message-ID: <_jAfqPK2do-_shiyviYHRZO4RBM6ZRn7D1M5bE1VMLI=.05588cad-6cbf-4112-856e-dfa08612327e@github.com>

On Fri, 22 May 2020 20:10:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1023:
>> 
>>> 1022:         set_ref_type_mirror(ref_type_oop, ref_type_oop);
>>> 1023:       }
>>> 1024:     }
>> 
>> With this code, if the super type of the inline type is `j.l.Object`, `Class:refType` will remain `null`. I'm not sure
>> that the VM code is ready to handle this situation. The only use case I've found is in
>> `LibraryCallKit::inline_value_Class_conversion(vmIntrinsics::ID id)` and I'm not familiar with it (the compiler team
>> might want to take a look at it).
>
> The current compiler implementation is left from LW2.  It needs update for the new language model and I suspect it does
> not depend on the ref type.
> Are you okay if I integrate this change now and follow up with the compiler team separately?

LibraryCallKit::inline_value_Class_conversion() implements the C2 intrinsics for asIndirectType/asPrimaryType which you
are removing anyway and is therefore not needed anymore. I have a patch ready that removes this and also removes all
the other remaining LW2 dependencies from the compiler code (JDK-8245729). I would suggest that it should go in first.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From thartmann at openjdk.java.net  Mon May 25 14:15:41 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 25 May 2020 14:15:41 GMT
Subject: [lworld] RFR: 8244931: [lworld] Decommission
 arrayStorageProperties from runtime null free and flat array tests
In-Reply-To: <3G9dEVHs5rPz51eC56wQnZ0r_55XfLXefaVTZ__iXrU=.e5e13781-c230-41a7-b0a8-5c54d752872b@github.com>
References: <3G9dEVHs5rPz51eC56wQnZ0r_55XfLXefaVTZ__iXrU=.e5e13781-c230-41a7-b0a8-5c54d752872b@github.com>
Message-ID: <FLkt9MAH1g6g4UVNLjzvvyDXWq2wFIr7ZJWF1xv1FJI=.ddf01c93-9b16-43a3-9cec-9041966c59fd@github.com>

On Mon, 25 May 2020 13:14:40 GMT, David Simms <dsimms at openjdk.org> wrote:

> Moved runtime and interpreter flat & null free tests to klass layout helper

Compiler changes look good to me!

-------------

PR: https://git.openjdk.java.net/valhalla/pull/54


From forax at univ-mlv.fr  Mon May 25 19:40:12 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 25 May 2020 21:40:12 +0200 (CEST)
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <cepdYZlN4b_vlv1Ym2q79WYcEcWc_N_IKhRyqBjuXyE=.ba5e9441-78db-4a5e-a827-b8f944634036@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
 <cepdYZlN4b_vlv1Ym2q79WYcEcWc_N_IKhRyqBjuXyE=.ba5e9441-78db-4a5e-a827-b8f944634036@github.com>
Message-ID: <1774825120.807166.1590435612762.JavaMail.zimbra@u-pem.fr>

[CC to Brian and amber-dev] because this is relevant to the API around record too. 

----- Mail original -----
> De: "John R Rose" <jrose at openjdk.java.net>
> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Samedi 23 Mai 2020 20:51:14
> Objet: Re: [lworld] RFR: 8245584: [lworld] LW3 core reflection update

> 
> One comment, really for the future, regarding the shape of the Java API here:
> It uses Optional and omits the "get"
> prefix on accessors.  This is the New Style, as opposed to the Classic Style
> using null (for "empty" results) and a
> "get" prefix ("getComponentType") to get a related type.  We may choose to to
> use the New Style for new reflection API
> points, and if so let's not choose N different New Styles, but one New Style.
> Personally I like removing "get"; I
> accept Optional instead of null; and I also suggest that arrays (if any) be
> replaced by (immutable) Lists in the New Style.

Please no, no New Style if the Old Style is good enough,
as a user i don't want to care if something was created a long ago or recently, if the API uses "get", or not, consistency is more important,
because it creates the feeling that you understand how the API works.

I think NetworkInterface [1] is the perfect example of how to evolve an API,
because it contains a mix between old, very old and new style.

1/ you have Enumeration used instead of Iterator because it's coherent with the java.net package that was created for Java 1, even if NetworkInterface was introduced in Java 4.
   even methods introduced in Java 6 uses Enumeration.
2/ recently some methods that returns a Stream were added.

I see two rules, one is when you grow an API follow the style of the API and if you have a good reason to introduce an API points with a new style, then provide both variants the old way and the new way.

regards,
R?mi

[1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/NetworkInterface.html



From dsimms at openjdk.java.net  Tue May 26 08:17:25 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 26 May 2020 08:17:25 GMT
Subject: [Integrated] [lworld] RFR: 8244931: [lworld] Decommission
 arrayStorageProperties from runtime null free and flat array tests
In-Reply-To: <3G9dEVHs5rPz51eC56wQnZ0r_55XfLXefaVTZ__iXrU=.e5e13781-c230-41a7-b0a8-5c54d752872b@github.com>
References: <3G9dEVHs5rPz51eC56wQnZ0r_55XfLXefaVTZ__iXrU=.e5e13781-c230-41a7-b0a8-5c54d752872b@github.com>
Message-ID: <DH7urN6mOXMrb5BTak7CM5l2ajiM16l_cYC3G6QcOCw=.57cc6df3-be7a-4061-a3fc-afa9b1e47623@github.com>

On Mon, 25 May 2020 13:14:40 GMT, David Simms <dsimms at openjdk.org> wrote:

> Moved runtime and interpreter flat & null free tests to klass layout helper

This pull request has now been integrated.

Changeset: eaf15771
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/eaf15771
Stats:     82 lines in 9 files changed: 6 ins; 53 del; 23 mod

8244931: [lworld] Decommission arrayStorageProperties from runtime null free and flat array tests

-------------

PR: https://git.openjdk.java.net/valhalla/pull/54


From thartmann at openjdk.java.net  Tue May 26 10:12:14 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 26 May 2020 10:12:14 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <_jAfqPK2do-_shiyviYHRZO4RBM6ZRn7D1M5bE1VMLI=.05588cad-6cbf-4112-856e-dfa08612327e@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
 <1Iod3fdCWBIV1jLgKJN9cM8qjxpdI1lq6VFuVXve5vc=.b60ba60a-0ad8-4047-9889-e93494624a1b@github.com>
 <_jAfqPK2do-_shiyviYHRZO4RBM6ZRn7D1M5bE1VMLI=.05588cad-6cbf-4112-856e-dfa08612327e@github.com>
Message-ID: <1iswjI0j9M-AL6NXdKWmQ5Mfjkehb2AGpsBja4_1H08=.7039853a-0562-4df9-8f30-d6b686d22dd5@github.com>

On Mon, 25 May 2020 14:01:51 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The current compiler implementation is left from LW2.  It needs update for the new language model and I suspect it does
>> not depend on the ref type.
>> Are you okay if I integrate this change now and follow up with the compiler team separately?
>
> LibraryCallKit::inline_value_Class_conversion() implements the C2 intrinsics for asIndirectType/asPrimaryType which you
> are removing anyway and is therefore not needed anymore. I have a patch ready that removes this and also removes all
> the other remaining LW2 dependencies from the compiler code (JDK-8245729). I would suggest that it should go in first.

PR is ready:
https://github.com/openjdk/valhalla/pull/55

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From thartmann at openjdk.java.net  Tue May 26 11:43:42 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 26 May 2020 11:43:42 GMT
Subject: [lworld] RFR: 8245729: [lworld] Adjust JIT code to reference
 projection changes
Message-ID: <dfBZUZQiVIiDTSJQGOpSc5EuyKbBhL-YNayKQ7Xm-Rg=.380f9ba5-4023-406f-94d1-69d912c8d4c2@github.com>

Changes:
- Removed all array storage properties related code
- Now using array tags in layout helper to determine flattened/null-free properties
- Removed handling of inline/indirect mirror
- Removed _asPrimaryType/_asIndirectType intrinsics and removed usages of corresponding API from tests
- Refactored loop unswitching code and added more tests
- Removed all special casing in the typesystem that was necessary to support [V <: [V? with the klass for [V not being
  equal to the klass for [V?

The code that clears the property bits when loading the klass pointer from the metadata is still in but marked with:
"// TODO remove clear_prop_bits bits stuff once the runtime does not set it anymore"

-------------

Commit messages:
 - 8245729: [lworld] Adjust JIT code to reference projection changes

Changes: https://git.openjdk.java.net/valhalla/pull/55/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/55/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245729
  Stats: 923 lines in 47 files changed: 156 ins; 503 del; 264 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/55.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/55/head:pull/55

PR: https://git.openjdk.java.net/valhalla/pull/55


From rwestrel at redhat.com  Tue May 26 12:43:02 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 26 May 2020 14:43:02 +0200
Subject: [lworld] RFR: 8245729: [lworld] Adjust JIT code to reference
 projection changes
In-Reply-To: <dfBZUZQiVIiDTSJQGOpSc5EuyKbBhL-YNayKQ7Xm-Rg=.380f9ba5-4023-406f-94d1-69d912c8d4c2@github.com>
References: <dfBZUZQiVIiDTSJQGOpSc5EuyKbBhL-YNayKQ7Xm-Rg=.380f9ba5-4023-406f-94d1-69d912c8d4c2@github.com>
Message-ID: <87imgi27ft.fsf@redhat.com>


>  Webrev: https://webrevs.openjdk.java.net/valhalla/55/webrev.00

Looks good to me.

Roland.



From thartmann at openjdk.java.net  Tue May 26 12:57:40 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 26 May 2020 12:57:40 GMT
Subject: [lworld] RFR: 8245729: [lworld] Adjust JIT code to reference
 projection changes
In-Reply-To: <dfBZUZQiVIiDTSJQGOpSc5EuyKbBhL-YNayKQ7Xm-Rg=.380f9ba5-4023-406f-94d1-69d912c8d4c2@github.com>
References: <dfBZUZQiVIiDTSJQGOpSc5EuyKbBhL-YNayKQ7Xm-Rg=.380f9ba5-4023-406f-94d1-69d912c8d4c2@github.com>
Message-ID: <fVlkVvqDN06yhwANXPe97URtYkWVE7em0qyV_tSeoj4=.d582a336-f0ee-4fa7-b7f8-662a9583bbb0@github.com>

On Tue, 26 May 2020 10:04:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Changes:
> - Removed all array storage properties related code
> - Now using array tags in layout helper to determine flattened/null-free properties
> - Removed handling of inline/indirect mirror
> - Removed _asPrimaryType/_asIndirectType intrinsics and removed usages of corresponding API from tests
> - Refactored loop unswitching code and added more tests
> - Removed all special casing in the typesystem that was necessary to support [V <: [V? with the klass for [V not being
>   equal to the klass for [V?
> 
> The code that clears the property bits when loading the klass pointer from the metadata is still in but marked with:
> "// TODO remove clear_prop_bits bits stuff once the runtime does not set it anymore"

Thanks Roland!

This pull request has now been integrated.

Changeset: e895128f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e895128f
Stats:     919 lines in 47 files changed: 499 ins; 152 del; 268 mod

8245729: [lworld] Adjust JIT code to reference projection changes

-------------

PR: https://git.openjdk.java.net/valhalla/pull/55


From thartmann at openjdk.java.net  Tue May 26 12:58:22 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 26 May 2020 12:58:22 GMT
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <1iswjI0j9M-AL6NXdKWmQ5Mfjkehb2AGpsBja4_1H08=.7039853a-0562-4df9-8f30-d6b686d22dd5@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
 <1Iod3fdCWBIV1jLgKJN9cM8qjxpdI1lq6VFuVXve5vc=.b60ba60a-0ad8-4047-9889-e93494624a1b@github.com>
 <_jAfqPK2do-_shiyviYHRZO4RBM6ZRn7D1M5bE1VMLI=.05588cad-6cbf-4112-856e-dfa08612327e@github.com>
 <1iswjI0j9M-AL6NXdKWmQ5Mfjkehb2AGpsBja4_1H08=.7039853a-0562-4df9-8f30-d6b686d22dd5@github.com>
Message-ID: <NZBYmdm2HU3-vuNnQmjbO1pGZZl0CRi_EOrUD1Qn8z4=.02eb63b1-d10f-4c8f-ab6f-e6b23eb5acd6@github.com>

On Tue, 26 May 2020 10:09:52 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> LibraryCallKit::inline_value_Class_conversion() implements the C2 intrinsics for asIndirectType/asPrimaryType which you
>> are removing anyway and is therefore not needed anymore. I have a patch ready that removes this and also removes all
>> the other remaining LW2 dependencies from the compiler code (JDK-8245729). I would suggest that it should go in first.
>
> PR is ready:
> https://github.com/openjdk/valhalla/pull/55

Pushed: https://github.com/openjdk/valhalla/commit/e895128f832a783b33937e7e317c191b813aa3db

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From dsimms at openjdk.java.net  Tue May 26 16:19:33 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 26 May 2020 16:19:33 GMT
Subject: [lworld] RFR: 8245809: [lworld] Remove the last traces of
 arrayStorageProperties
Message-ID: <jHVqqff1HPWxAcWJ_bgdPQm2v53Eow71J7VL4LkAGFU=.797b5212-cc03-452b-b307-b2b5a14631a4@github.com>

Removed arrayStorageProperties

-------------

Commit messages:
 - 8245809: [lworld] Remove the last traces of arrayStorageProperties

Changes: https://git.openjdk.java.net/valhalla/pull/56/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/56/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245809
  Stats: 299 lines in 15 files changed: 1 ins; 283 del; 15 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/56.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/56/head:pull/56

PR: https://git.openjdk.java.net/valhalla/pull/56


From fparain at openjdk.java.net  Tue May 26 18:27:49 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 26 May 2020 18:27:49 GMT
Subject: [lworld] RFR: 8245809: [lworld] Remove the last traces of
 arrayStorageProperties
In-Reply-To: <jHVqqff1HPWxAcWJ_bgdPQm2v53Eow71J7VL4LkAGFU=.797b5212-cc03-452b-b307-b2b5a14631a4@github.com>
References: <jHVqqff1HPWxAcWJ_bgdPQm2v53Eow71J7VL4LkAGFU=.797b5212-cc03-452b-b307-b2b5a14631a4@github.com>
Message-ID: <e7xKQPzoeylun1IB2NSMZm1F_u8RpAE9GWg93jJKYp0=.6047b6d8-dac7-4962-9424-efa72db69ef7@github.com>

On Tue, 26 May 2020 15:46:45 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed arrayStorageProperties

Changes look good to me.

Fred

-------------

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/56


From fparain at openjdk.java.net  Tue May 26 18:57:34 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 26 May 2020 18:57:34 GMT
Subject: [lworld] RFR: 8245646: [lworld] LW3 Reduce impact of IdentityObject
 on metaspace
Message-ID: <t7D0TcjjleJab1rD77TwZ1gXyy-rz3aaDsuOX9Q3G9Q=.cebd3ed3-35b1-49df-a2ed-c97dc2d64005@github.com>

Please review these changes for JDK-8245646.

This is not a new feature, just an optimization to reduce the number klass arrays containing only `IdentityObject`
begin allocated in metaspaces.

Thank you,

Fred

-------------

Commit messages:
 - Implement shared class array containing IdentityObject

Changes: https://git.openjdk.java.net/valhalla/pull/57/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/57/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245646
  Stats: 35 lines in 4 files changed: 33 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/57.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/57/head:pull/57

PR: https://git.openjdk.java.net/valhalla/pull/57


From mchung at openjdk.java.net  Tue May 26 18:59:31 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 May 2020 18:59:31 GMT
Subject: [lworld] [Rev 01] RFR: 8245584: [lworld] LW3 core reflection
 update
In-Reply-To: <NZBYmdm2HU3-vuNnQmjbO1pGZZl0CRi_EOrUD1Qn8z4=.02eb63b1-d10f-4c8f-ab6f-e6b23eb5acd6@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
 <1Iod3fdCWBIV1jLgKJN9cM8qjxpdI1lq6VFuVXve5vc=.b60ba60a-0ad8-4047-9889-e93494624a1b@github.com>
 <_jAfqPK2do-_shiyviYHRZO4RBM6ZRn7D1M5bE1VMLI=.05588cad-6cbf-4112-856e-dfa08612327e@github.com>
 <1iswjI0j9M-AL6NXdKWmQ5Mfjkehb2AGpsBja4_1H08=.7039853a-0562-4df9-8f30-d6b686d22dd5@github.com>
 <NZBYmdm2HU3-vuNnQmjbO1pGZZl0CRi_EOrUD1Qn8z4=.02eb63b1-d10f-4c8f-ab6f-e6b23eb5acd6@github.com>
Message-ID: <sBXGZ4TOjgmBpKODeJuReddVlwUu0Isyqqm5D9HdKg8=.a7ad0792-4d2d-4610-b2e1-d9f765460f70@github.com>

On Tue, 26 May 2020 12:56:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> PR is ready:
>> https://github.com/openjdk/valhalla/pull/55
>
> Pushed: https://github.com/openjdk/valhalla/commit/e895128f832a783b33937e7e317c191b813aa3db

Tobias, thanks.  I now have updated the patch to take out the functions that are no longer needed by JIT.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From mchung at openjdk.java.net  Tue May 26 18:59:31 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 May 2020 18:59:31 GMT
Subject: [lworld] [Rev 01] RFR: 8245584: [lworld] LW3 core reflection
 update
In-Reply-To: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
Message-ID: <QC-QeXRd6G9_6oNaUOOHXsmN6X7DXFZDoAhHIwWf5tg=.aac66001-5f23-42b3-9a57-4c5d16cc9f45@github.com>

> This patch updates the core reflection for the new language model for inline classes.
> 
> - `Class::isInlineClass` returns true for inline classes
> - `Class::valueType` returns the value projection of an inline class
> - `Class::referenceType` returns the reference projection if it's an inline class,
>     or this class if it's not an inline class
> 
> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
> where  we can rather than holding to the tradition.
> 
> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
> and `Class:asIndirectType` is removed.

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains five commits:

 - Remove unused methods no longer needed by JIT
 - Merge
 - minor adjustment per review feedback
 - Class::valueType and Class::referenceType return Optional
 - 8245584: [lworld] LW3 core reflection update

-------------

Changes: https://git.openjdk.java.net/valhalla/pull/53/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/53/webrev.01
  Stats: 495 lines in 34 files changed: 44 ins; 255 del; 196 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/53.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/53/head:pull/53

PR: https://git.openjdk.java.net/valhalla/pull/53


From mandy.chung at oracle.com  Tue May 26 18:59:36 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 26 May 2020 11:59:36 -0700
Subject: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
In-Reply-To: <1774825120.807166.1590435612762.JavaMail.zimbra@u-pem.fr>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
 <boxmFg9b1G-VR6Cpm2lTYr5m4onqmNEu8pAViR5gXv4=.a894d010-bba2-4ae5-a3f3-524636febc1d@github.com>
 <cepdYZlN4b_vlv1Ym2q79WYcEcWc_N_IKhRyqBjuXyE=.ba5e9441-78db-4a5e-a827-b8f944634036@github.com>
 <1774825120.807166.1590435612762.JavaMail.zimbra@u-pem.fr>
Message-ID: <4db25c49-b008-1f8e-edab-efdbdc0bdfb0@oracle.com>



On 5/25/20 12:40 PM, Remi Forax wrote:
> [CC to Brian and amber-dev] because this is relevant to the API around record too.
>
> ----- Mail original -----
>> De: "John R Rose" <jrose at openjdk.java.net>
>> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoy?: Samedi 23 Mai 2020 20:51:14
>> Objet: Re: [lworld] RFR: 8245584: [lworld] LW3 core reflection update
>> One comment, really for the future, regarding the shape of the Java API here:
>> It uses Optional and omits the "get"
>> prefix on accessors.  This is the New Style, as opposed to the Classic Style
>> using null (for "empty" results) and a
>> "get" prefix ("getComponentType") to get a related type.  We may choose to to
>> use the New Style for new reflection API
>> points, and if so let's not choose N different New Styles, but one New Style.
>> Personally I like removing "get"; I
>> accept Optional instead of null; and I also suggest that arrays (if any) be
>> replaced by (immutable) Lists in the New Style.
> Please no, no New Style if the Old Style is good enough,
> as a user i don't want to care if something was created a long ago or recently, if the API uses "get", or not, consistency is more important,
> because it creates the feeling that you understand how the API works.
>
> I think NetworkInterface [1] is the perfect example of how to evolve an API,
> because it contains a mix between old, very old and new style.
>
> 1/ you have Enumeration used instead of Iterator because it's coherent with the java.net package that was created for Java 1, even if NetworkInterface was introduced in Java 4.
>     even methods introduced in Java 6 uses Enumeration.
> 2/ recently some methods that returns a Stream were added.
>
> I see two rules, one is when you grow an API follow the style of the API and if you have a good reason to introduce an API points with a new style, then provide both variants the old way and the new way.

IMO, adding both old way and the new way bloats the API unnecessarily.

Note that the java.lang.Class API implements TypeDescriptor.ofField 
which already introduces the new style APIs, Class::describeConstable 
and Class::arrayType etc.

Mandy
> regards,
> R?mi
>
> [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/NetworkInterface.html
>



From mchung at openjdk.java.net  Tue May 26 19:25:55 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 May 2020 19:25:55 GMT
Subject: [Integrated] [lworld] RFR: 8245584: [lworld] LW3 core reflection
 update
In-Reply-To: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
References: <rfQUvfy83ajcu99ftcBSAZiAZZDWWDW4axdwhzPF7W8=.c5d434f3-95fc-47c4-be98-dcf9f432af9f@github.com>
Message-ID: <x0g4iW5VTbnvW0ULkOUVlTLgI7A3PTAQpsqwPq88sJ0=.04434987-0679-4b8a-a1be-621e6656baff@github.com>

On Thu, 21 May 2020 22:09:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This patch updates the core reflection for the new language model for inline classes.
> 
> - `Class::isInlineClass` returns true for inline classes
> - `Class::valueType` returns the value projection of an inline class
> - `Class::referenceType` returns the reference projection if it's an inline class,
>     or this class if it's not an inline class
> 
> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
> where  we can rather than holding to the tradition.
> 
> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
> and `Class:asIndirectType` is removed.

This pull request has now been integrated.

Changeset: 9a83d9b6
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9a83d9b6
Stats:     498 lines in 34 files changed: 258 ins; 47 del; 193 mod

8245584: [lworld] LW3 core reflection update

Reviewed-by: fparain

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53


From dsimms at openjdk.java.net  Wed May 27 05:49:09 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 27 May 2020 05:49:09 GMT
Subject: [Integrated] [lworld] RFR: 8245809: [lworld] Remove the last
 traces of arrayStorageProperties
In-Reply-To: <jHVqqff1HPWxAcWJ_bgdPQm2v53Eow71J7VL4LkAGFU=.797b5212-cc03-452b-b307-b2b5a14631a4@github.com>
References: <jHVqqff1HPWxAcWJ_bgdPQm2v53Eow71J7VL4LkAGFU=.797b5212-cc03-452b-b307-b2b5a14631a4@github.com>
Message-ID: <nksBQJtnHcVGIxtsi9G3Fd6D41LihtKuHLJDKNe8Y2c=.89f1d971-d6bd-4727-9991-6709b4d68168@github.com>

On Tue, 26 May 2020 15:46:45 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed arrayStorageProperties

This pull request has now been integrated.

Changeset: 8422fb48
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/8422fb48
Stats:     299 lines in 15 files changed: 283 ins; 1 del; 15 mod

8245809: [lworld] Remove the last traces of arrayStorageProperties

Reviewed-by: fparain

-------------

PR: https://git.openjdk.java.net/valhalla/pull/56


From dsimms at openjdk.java.net  Wed May 27 05:52:51 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 27 May 2020 05:52:51 GMT
Subject: [lworld] RFR: 8245646: [lworld] LW3 Reduce impact of
 IdentityObject on metaspace
In-Reply-To: <t7D0TcjjleJab1rD77TwZ1gXyy-rz3aaDsuOX9Q3G9Q=.cebd3ed3-35b1-49df-a2ed-c97dc2d64005@github.com>
References: <t7D0TcjjleJab1rD77TwZ1gXyy-rz3aaDsuOX9Q3G9Q=.cebd3ed3-35b1-49df-a2ed-c97dc2d64005@github.com>
Message-ID: <skPaC2LtvjTTOlJU4m0KDIkx8ths3XwiKzk3TCqjDM8=.db5d0ad4-13b9-40a1-8c7d-e5f8c23757a6@github.com>

On Tue, 26 May 2020 18:49:54 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes for JDK-8245646.
> 
> This is not a new feature, just an optimization to reduce the number klass arrays containing only `IdentityObject`
> begin allocated in metaspaces.
> Thank you,
> 
> Fred

Looks good.

-------------

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/57


From thartmann at openjdk.java.net  Wed May 27 11:01:09 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 27 May 2020 11:01:09 GMT
Subject: [Integrated] [lworld] FYI: 8245953: [lworld] Remove array storage
 property bits clearing from JIT code
In-Reply-To: <8R8X8EpHuvRwUXdZCNGdEUcufZwuWW6H26POFcZN49c=.e60b4972-aeb4-4737-8a09-9387e3f01b1b@github.com>
References: <8R8X8EpHuvRwUXdZCNGdEUcufZwuWW6H26POFcZN49c=.e60b4972-aeb4-4737-8a09-9387e3f01b1b@github.com>
Message-ID: <x2VBRbgThoxXyYlhipqi__tSm9z-owEbbaa125sTV7U=.800cdfe7-c255-4192-8efc-a2ba0b37d42b@github.com>

On Wed, 27 May 2020 10:52:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Removed all code that clears the storage property bits when loading the klass pointer. Also adjusted tests.

This pull request has now been integrated.

Changeset: 27e8b6e0
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/27e8b6e0
Stats:     73 lines in 13 files changed: 44 ins; 0 del; 29 mod

8245953: [lworld] Remove array storage property bits clearing from JIT code

-------------

PR: https://git.openjdk.java.net/valhalla/pull/59


From thartmann at openjdk.java.net  Wed May 27 11:01:08 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 27 May 2020 11:01:08 GMT
Subject: [lworld] FYI: 8245953: [lworld] Remove array storage property bits
 clearing from JIT code
Message-ID: <8R8X8EpHuvRwUXdZCNGdEUcufZwuWW6H26POFcZN49c=.e60b4972-aeb4-4737-8a09-9387e3f01b1b@github.com>

Removed all code that clears the storage property bits when loading the klass pointer. Also adjusted tests.

-------------

Commit messages:
 - 8245953: [lworld] Remove array storage property bits clearing from JIT code

Changes: https://git.openjdk.java.net/valhalla/pull/59/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/59/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245953
  Stats: 73 lines in 13 files changed: 0 ins; 44 del; 29 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/59.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/59/head:pull/59

PR: https://git.openjdk.java.net/valhalla/pull/59


From fparain at openjdk.java.net  Wed May 27 12:16:57 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 27 May 2020 12:16:57 GMT
Subject: [Integrated] [lworld] RFR: 8245646: [lworld] LW3 Reduce impact of
 IdentityObject on metaspace
In-Reply-To: <t7D0TcjjleJab1rD77TwZ1gXyy-rz3aaDsuOX9Q3G9Q=.cebd3ed3-35b1-49df-a2ed-c97dc2d64005@github.com>
References: <t7D0TcjjleJab1rD77TwZ1gXyy-rz3aaDsuOX9Q3G9Q=.cebd3ed3-35b1-49df-a2ed-c97dc2d64005@github.com>
Message-ID: <vyWZamguI4501rRPNFm__6H6564hdOJIEd90idmi8j8=.c26a408f-9083-4a80-a29a-f6779181bc51@github.com>

On Tue, 26 May 2020 18:49:54 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes for JDK-8245646.
> 
> This is not a new feature, just an optimization to reduce the number klass arrays containing only `IdentityObject`
> begin allocated in metaspaces.
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: ed7a00c6
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ed7a00c6
Stats:     35 lines in 4 files changed: 0 ins; 33 del; 2 mod

8245646: [lworld] LW3 Reduce impact of IdentityObject on metaspace

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.java.net/valhalla/pull/57


From fparain at openjdk.java.net  Wed May 27 19:51:46 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 27 May 2020 19:51:46 GMT
Subject: [lworld] RFR: 8246014: [lworld] [lw3]
 serviceability/sa/ClhsdbDumpclass.java is failing for a while
Message-ID: <-k_kO7MWimzBvmw4pEJgeAooj8VT5mNUBgC19jX4oTs=.00f9a4a2-71fb-4bef-bef5-97a5440292c7@github.com>

Please review these changes fixing the HotSpot agent enough so test serviceability/sa/ClhsdbDumpclass.java would stop
failing.

Thank you,

Fred

-------------

Commit messages:
 - Fixes in HotSpot agent: bytecodes numbering and injected interfaces

Changes: https://git.openjdk.java.net/valhalla/pull/60/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/60/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246014
  Stats: 45 lines in 2 files changed: 6 ins; 0 del; 39 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/60/head:pull/60

PR: https://git.openjdk.java.net/valhalla/pull/60


From hseigel at openjdk.java.net  Wed May 27 20:50:02 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 27 May 2020 20:50:02 GMT
Subject: [lworld] RFR: 8246014: [lworld] [lw3]
 serviceability/sa/ClhsdbDumpclass.java is failing for a while
In-Reply-To: <-k_kO7MWimzBvmw4pEJgeAooj8VT5mNUBgC19jX4oTs=.00f9a4a2-71fb-4bef-bef5-97a5440292c7@github.com>
References: <-k_kO7MWimzBvmw4pEJgeAooj8VT5mNUBgC19jX4oTs=.00f9a4a2-71fb-4bef-bef5-97a5440292c7@github.com>
Message-ID: <cuPYNINoV5ePudxP-X-zosrRGDHRclaTwar5CDB-cD0=.ed60d8ca-01ad-4f07-acb7-7a3770901b27@github.com>

On Wed, 27 May 2020 19:45:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes fixing the HotSpot agent enough so test serviceability/sa/ClhsdbDumpclass.java would stop
> failing.
> Thank you,
> 
> Fred

Looks good.

-------------

Marked as reviewed by hseigel (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/60


From fparain at openjdk.java.net  Wed May 27 21:00:08 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 27 May 2020 21:00:08 GMT
Subject: [Integrated] [lworld] RFR: 8246014: [lworld] [lw3]
 serviceability/sa/ClhsdbDumpclass.java is failing for a while
In-Reply-To: <-k_kO7MWimzBvmw4pEJgeAooj8VT5mNUBgC19jX4oTs=.00f9a4a2-71fb-4bef-bef5-97a5440292c7@github.com>
References: <-k_kO7MWimzBvmw4pEJgeAooj8VT5mNUBgC19jX4oTs=.00f9a4a2-71fb-4bef-bef5-97a5440292c7@github.com>
Message-ID: <s9Jd-zG_ADWfH-EQwJdCZzKfCLDIfjHyI8vMyegJim4=.5c31879b-9938-4c6e-825b-314ef7d61005@github.com>

On Wed, 27 May 2020 19:45:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes fixing the HotSpot agent enough so test serviceability/sa/ClhsdbDumpclass.java would stop
> failing.
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 3dee5f5e
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3dee5f5e
Stats:     45 lines in 2 files changed: 0 ins; 6 del; 39 mod

8246014: [lworld] [lw3] serviceability/sa/ClhsdbDumpclass.java is failing for a while

Reviewed-by: hseigel

-------------

PR: https://git.openjdk.java.net/valhalla/pull/60


From fparain at openjdk.java.net  Wed May 27 21:00:07 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 27 May 2020 21:00:07 GMT
Subject: [lworld] RFR: 8246014: [lworld] [lw3]
 serviceability/sa/ClhsdbDumpclass.java is failing for a while
In-Reply-To: <cuPYNINoV5ePudxP-X-zosrRGDHRclaTwar5CDB-cD0=.ed60d8ca-01ad-4f07-acb7-7a3770901b27@github.com>
References: <-k_kO7MWimzBvmw4pEJgeAooj8VT5mNUBgC19jX4oTs=.00f9a4a2-71fb-4bef-bef5-97a5440292c7@github.com>
 <cuPYNINoV5ePudxP-X-zosrRGDHRclaTwar5CDB-cD0=.ed60d8ca-01ad-4f07-acb7-7a3770901b27@github.com>
Message-ID: <_z0N1plyOQ8FbFHn8ESrcatNQIMyoQBD__vyXMIT_Ak=.d9d4cd11-7bd2-43a2-ac12-2726dcfae595@github.com>

On Wed, 27 May 2020 20:47:50 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review these changes fixing the HotSpot agent enough so test serviceability/sa/ClhsdbDumpclass.java would stop
>> failing.
>> Thank you,
>> 
>> Fred
>
> Looks good.

Thank you Harold.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/60