From zekerzhayard at gmail.com  Mon Oct  4 09:50:30 2021
From: zekerzhayard at gmail.com (Zeker Zhayard)
Date: Mon, 4 Oct 2021 17:50:30 +0800
Subject: Different behaviors of Ref_InvokeSpecial
Message-ID: <CAD1iG+mY=cThHFnYRykgrn4ouP7=u1s0becBGb8QbAJ4BOki3A@mail.gmail.com>

Hi,
JEP 371 describes that to invoke private nestmate instance methods from
code in a hidden class, use invokevirtual or invokeinterface instead of
invokespecial and generated bytecode that uses invokespecial to invoke a
private nestmate instance method will fail verification. invokespecial
should only be used to invoke private nestmate constructors.
However, consider the following use case:

import java.util.function.Supplier;

public class ExampleClass {
    public static void main(String[] args) {
        System.out.println(new SubClass().test());
    }

    public String test() {
        Supplier<String> supplier = this::testPrivate;
        return supplier.get();
    }

    private String testPrivate() {
        return "123";
    }

    public static class SubClass extends ExampleClass {
        public String testPrivate() {
            return "456";
        }
    }
}

1. Compile it with Java 8
2. Modify the access of ExampleClass#testPrivate to protected in bytecode
3. Running in Java 15+ will get "456" rather than "123" in Java 8~14


From liangchenblue at gmail.com  Mon Oct  4 12:38:06 2021
From: liangchenblue at gmail.com (-)
Date: Mon, 4 Oct 2021 07:38:06 -0500
Subject: Different behaviors of Ref_InvokeSpecial
In-Reply-To: <CAD1iG+mY=cThHFnYRykgrn4ouP7=u1s0becBGb8QbAJ4BOki3A@mail.gmail.com>
References: <CAD1iG+mY=cThHFnYRykgrn4ouP7=u1s0becBGb8QbAJ4BOki3A@mail.gmail.com>
Message-ID: <CABe8uE3rum0jHmV_LLZN5dbr0eEhMhqBk-Z3VE8VAEbLSW=OUg@mail.gmail.com>

Hello,
Bystander here. This comment in code [1] may be related information.

The question here is more like how the access to methods should be
changed. In prior versions, if you want to expose a private method to
be overridable, you have to change all calls to it from invokespecial
to invokevirtual, and it's no surprise if you need extra housekeeping
around simple access changes. But let's take a step back, why are we
changing the access of these methods at all, and how are they
necessary?

Sending this to jdk-dev as this is related to jdk itself than valhalla.

Best regards

[1] https://github.com/openjdk/jdk/blob/0828273b898cca5368344e75f1c3f4c3a29dde80/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L157


From vromero at openjdk.java.net  Mon Oct  4 20:38:29 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 4 Oct 2021 20:38:29 GMT
Subject: Integrated: Merge lworld
Message-ID: <tyysDASlBn_F-cWh32wtOVqQOUhwdOWYbByZbnPTusk=.ff7611f7-41e1-43d2-8f77-d12d34eca7c2@github.com>

Merging lworld into universal-tvars

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

Commit messages:
 - Merge lworld
 - Merge lworld
 - universal type variables: initial prototype
 - Merge lworld
 - Merge lworld
 - Merge lworld

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/valhalla/pull/557/files
  Stats: 756 lines in 22 files changed: 717 ins; 1 del; 38 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/557.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/557/head:pull/557

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


From vromero at openjdk.java.net  Mon Oct  4 20:38:31 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 4 Oct 2021 20:38:31 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <tyysDASlBn_F-cWh32wtOVqQOUhwdOWYbByZbnPTusk=.ff7611f7-41e1-43d2-8f77-d12d34eca7c2@github.com>
References: <tyysDASlBn_F-cWh32wtOVqQOUhwdOWYbByZbnPTusk=.ff7611f7-41e1-43d2-8f77-d12d34eca7c2@github.com>
Message-ID: <aThW7Pm0UsJtaCuZAM3I9BOJsnP8SJTD9AeIe4dPskI=.18790c36-5f90-474a-aaf8-b0c35b31980d@github.com>

On Mon, 4 Oct 2021 20:28:21 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merging lworld into universal-tvars

This pull request has now been integrated.

Changeset: c3625a41
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c3625a41c90f864ce34610046b7ed27d507a92c2
Stats:     33186 lines in 1045 files changed: 24749 ins; 4855 del; 3582 mod

Merge lworld

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

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


From mandy.chung at oracle.com  Mon Oct  4 20:59:39 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 4 Oct 2021 13:59:39 -0700
Subject: Different behaviors of Ref_InvokeSpecial
In-Reply-To: <CAD1iG+mY=cThHFnYRykgrn4ouP7=u1s0becBGb8QbAJ4BOki3A@mail.gmail.com>
References: <CAD1iG+mY=cThHFnYRykgrn4ouP7=u1s0becBGb8QbAJ4BOki3A@mail.gmail.com>
Message-ID: <cb662ca2-2dc4-fb52-c380-c678bc0171a7@oracle.com>

(valhalla-dev is a proper mailing list to discuss that.? I bcc jdk-dev).

Hi Zeker,

Which version of javac are you using?? I compiled it with JDK 8u331 and 
can't reproduce the problem.

$ jdk1.8.0_311.jdk/bin/java -version
java version "1.8.0_311-ea"
Java(TM) SE Runtime Environment (build 1.8.0_311-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.311-b01, mixed mode)

$ jdk1.8.0_311.jdk/bin/javac -version
javac 1.8.0_311-ea

$ jdk1.8.0_311.jdk/bin/javac ExampleClass.java
$ jdk1.8.0_311.jdk/bin/java ExampleClass
123

$ jdk-15.jdk/bin/java -version
java version "15" 2020-09-15
Java(TM) SE Runtime Environment (build 15+36-1562)
Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)

$ jdk-15.jdk/bin/java ExampleClass
123


Note that the JVMS change related to invokespecial is part of JEP 181 
Nest-based Access Control.? The hidden classes generated by 
LambdaMetaFactory is a nestmate of the target class and so the bytecode 
generated was fixed in JEP 371 to use invokevirtual or invokeinterface 
per JVMS.

The bootstrap method javac generated is REF_invokeSpecial in your 
ExampleClass.? LMF does special handle it for compatibility for existing 
code to behave as in older releases.

BootstrapMethods:
 ? 0: #34 REF_invokeStatic 
java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
 ??? Method arguments:
 ????? #35 ()Ljava/lang/Object;
 ????? #36 REF_invokeSpecial ExampleClass.testPrivate:()Ljava/lang/String;
 ????? #37 ()Ljava/lang/String;


I don't see any issue from ExampleClass.

Mandy

On 10/4/21 2:50 AM, Zeker Zhayard wrote:
> Hi,
> JEP 371 describes that to invoke private nestmate instance methods from
> code in a hidden class, use invokevirtual or invokeinterface instead of
> invokespecial and generated bytecode that uses invokespecial to invoke a
> private nestmate instance method will fail verification. invokespecial
> should only be used to invoke private nestmate constructors.
> However, consider the following use case:
>
> import java.util.function.Supplier;
>
> public class ExampleClass {
>      public static void main(String[] args) {
>          System.out.println(new SubClass().test());
>      }
>
>      public String test() {
>          Supplier<String> supplier = this::testPrivate;
>          return supplier.get();
>      }
>
>      private String testPrivate() {
>          return "123";
>      }
>
>      public static class SubClass extends ExampleClass {
>          public String testPrivate() {
>              return "456";
>          }
>      }
> }
>
> 1. Compile it with Java 8
> 2. Modify the access of ExampleClass#testPrivate to protected in bytecode
> 3. Running in Java 15+ will get "456" rather than "123" in Java 8~14



From fparain at openjdk.java.net  Tue Oct  5 18:54:30 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 5 Oct 2021 18:54:30 GMT
Subject: [lworld] RFR: 8274792: [lworld] Final fields should be flattened
Message-ID: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>

Small fix triggering flattening of non-static fields.

Fred

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

Commit messages:
 - Flatten final fields

Changes: https://git.openjdk.java.net/valhalla/pull/558/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=558&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274792
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/558.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/558/head:pull/558

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


From thartmann at openjdk.java.net  Wed Oct  6 06:14:17 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 6 Oct 2021 06:14:17 GMT
Subject: [lworld] RFR: 8274792: [lworld] Final fields should be flattened
In-Reply-To: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
References: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
Message-ID: <M1towty-ZzU8txogwZTBmN4nrBViTrFIoHc2gqTJIUc=.2ee5bca8-2e39-4662-8534-93232d5906df@github.com>

On Tue, 5 Oct 2021 18:48:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix triggering flattening of non-static fields.
> 
> Fred

Shouldn't `too_big_to_flatten` still be respected?

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

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


From fparain at openjdk.java.net  Wed Oct  6 12:57:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 6 Oct 2021 12:57:22 GMT
Subject: [lworld] RFR: 8274792: [lworld] Final fields should be flattened
In-Reply-To: <M1towty-ZzU8txogwZTBmN4nrBViTrFIoHc2gqTJIUc=.2ee5bca8-2e39-4662-8534-93232d5906df@github.com>
References: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
 <M1towty-ZzU8txogwZTBmN4nrBViTrFIoHc2gqTJIUc=.2ee5bca8-2e39-4662-8534-93232d5906df@github.com>
Message-ID: <dc3wcJuD4ic1anx8t5n-0IR0uxRjs825vanRjNv2Lcw=.dbb63407-5e93-4f9c-94bc-b8238325a014@github.com>

On Wed, 6 Oct 2021 06:11:49 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Shouldn't `too_big_to_flatten` still be respected?

The rational of not flattening big values was to avoid the cost of copying such big payload over and over again.
Final fields are updated only once, so the number of copy to be performed is low.
The interpreter and C1 would have to make those copy anyway (always buffering), but C2 would benefit from this flattening because it would have one less indirection, and it only reads the fields of the value it really needs.

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

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


From thartmann at openjdk.java.net  Wed Oct  6 13:02:25 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 6 Oct 2021 13:02:25 GMT
Subject: [lworld] RFR: 8274792: [lworld] Final fields should be flattened
In-Reply-To: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
References: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
Message-ID: <LQwviVpjFVt_9eY7kr-mJ23-9pHy_FU3k1Fsit5tN-A=.9b465eaa-1dc9-4a7a-9ac4-70169a346c6c@github.com>

On Tue, 5 Oct 2021 18:48:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix triggering flattening of non-static fields.
> 
> Fred

Okay, thanks for the details. Looks good to me.

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

Marked as reviewed by thartmann (Committer).

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


From fparain at openjdk.java.net  Wed Oct  6 13:13:20 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 6 Oct 2021 13:13:20 GMT
Subject: [lworld] RFR: 8274792: [lworld] Final fields should be flattened
In-Reply-To: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
References: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
Message-ID: <PqmdziZLiB4h3s6JqLEaN8vOdLQcb2uGIpzj_zVft0s=.293473c7-50c2-4280-bb75-348941b19e54@github.com>

On Tue, 5 Oct 2021 18:48:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix triggering flattening of non-static fields.
> 
> Fred

Thanks for the review.

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

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


From fparain at openjdk.java.net  Wed Oct  6 13:13:21 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 6 Oct 2021 13:13:21 GMT
Subject: [lworld] Integrated: 8274792: [lworld] Final fields should be
 flattened
In-Reply-To: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
References: <wuSBNOwSYLKaV0cmi32ae-OcLWtRz4lZXKeRxl3-leE=.2da04550-09ee-43a7-bcb6-540f71667f7f@github.com>
Message-ID: <GnPrqMWH8aSQZkL1is9oBQuRNmfJxUxy1cJTSaxBgDo=.6bdf24b3-fb84-480e-a2f0-3147cfd39fba@github.com>

On Tue, 5 Oct 2021 18:48:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix triggering flattening of non-static fields.
> 
> Fred

This pull request has now been integrated.

Changeset: 3f5d92fb
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3f5d92fb5f0d35a33d9448bc703e11a64d5ca4e6
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8274792: [lworld] Final fields should be flattened

Reviewed-by: thartmann

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

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


From zjx001202 at gmail.com  Wed Oct  6 15:45:39 2021
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 6 Oct 2021 23:45:39 +0800
Subject: Will lambda expressions become primitive objects?
Message-ID: <CAJL5A3kqYYe_1gm9ZN_MDzLhME4oCiz_MYQh==8m9ci6m=h4Cg@mail.gmail.com>

Objects created by lambda expressions seem to meet the limitations of
primitive objects. At present, the object created by lambda expression
still seems to be identity object, making them primitive objects may
reduce the creation of unnecessary objects in the absence of inlining.
So I'm curious if you have such plans?

I don't know if a lot of code depends on the object identity of lambda
expressions, If the object identity of a lambda expression cannot be
removed for compatibility, can you consider supporting such a simple
way to create a lambda expression that is a primitive object:

  var runnable = (Runnable & PrimitiveObject) () -> {};


From brian.goetz at oracle.com  Wed Oct  6 16:23:07 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 6 Oct 2021 16:23:07 +0000
Subject: Will lambda expressions become primitive objects?
In-Reply-To: <CAJL5A3kqYYe_1gm9ZN_MDzLhME4oCiz_MYQh==8m9ci6m=h4Cg@mail.gmail.com>
References: <CAJL5A3kqYYe_1gm9ZN_MDzLhME4oCiz_MYQh==8m9ci6m=h4Cg@mail.gmail.com>
Message-ID: <BB783388-F35D-423E-B481-83C19BBC0548@oracle.com>

Yes, these are reasonable candidates for losing their identity.  In fact, if you read the JLS, you?ll see that we make no guarantees on the identity of the lambda object.  That was a deliberately planted stake in the ground ?.

Sent from my iPad

> On Oct 6, 2021, at 11:46 AM, Glavo <zjx001202 at gmail.com> wrote:
> 
> ?Objects created by lambda expressions seem to meet the limitations of
> primitive objects. At present, the object created by lambda expression
> still seems to be identity object, making them primitive objects may
> reduce the creation of unnecessary objects in the absence of inlining.
> So I'm curious if you have such plans?
> 
> I don't know if a lot of code depends on the object identity of lambda
> expressions, If the object identity of a lambda expression cannot be
> removed for compatibility, can you consider supporting such a simple
> way to create a lambda expression that is a primitive object:
> 
>  var runnable = (Runnable & PrimitiveObject) () -> {};

From jesper at selskabet.org  Fri Oct  8 12:46:11 2021
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Fri, 8 Oct 2021 14:46:11 +0200
Subject: Primitive classes can't be retransformed (yet?)
Message-ID: <A535AABD-4989-496F-9853-A63557D0282D@selskabet.org>

Hi Valhallians

From looking at the interaction between primitive classes and records, I stumbled upon a problem with redefining primitive classes through JVMTI. I tried fixing it myself, but it really needs the attention of one of the elders. My finding are at https://bugs.openjdk.java.net/browse/JDK-8274800 <https://bugs.openjdk.java.net/browse/JDK-8274800> where there?s also a link to my branch with the attempted fix.

-Jesper

From dsimms at openjdk.java.net  Mon Oct 11 08:59:59 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 11 Oct 2021 08:59:59 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <sVhlPTB0JmlxXay3aw4LlRHPbjdfrhHZ3ibxJwanCFo=.3d2d49ca-15c7-4c25-a6df-c29da688e526@github.com>

Merge jdk-18+18

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

Commit messages:
 - Merge error
 - Merge tag 'jdk-18+18' into lworld_merge_jdk_20210921
 - 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management
 - 8274525: Replace uses of StringBuffer with StringBuilder in java.xml
 - 8273711: Remove redundant stream() call before forEach in jdk.jlink
 - 8274464: Remove redundant stream() call before forEach in java.* modules
 - 8262944: Improve exception message when automatic module lists provider class not in JAR file
 - 8273917: Remove 'leaf' ranking for Mutex
 - 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm
 - 8274496: Use String.contains() instead of String.indexOf() in java.desktop
 - ... and 505 more: https://git.openjdk.java.net/valhalla/compare/3f5d92fb...216bef67

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=559&range=00.0
 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=559&range=00.1

Changes: https://git.openjdk.java.net/valhalla/pull/559/files
  Stats: 60525 lines in 1999 files changed: 38976 ins; 11572 del; 9977 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/559/head:pull/559

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


From dsimms at openjdk.java.net  Mon Oct 11 09:03:35 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 11 Oct 2021 09:03:35 GMT
Subject: [lworld] RFR: Merge jdk
In-Reply-To: <sVhlPTB0JmlxXay3aw4LlRHPbjdfrhHZ3ibxJwanCFo=.3d2d49ca-15c7-4c25-a6df-c29da688e526@github.com>
References: <sVhlPTB0JmlxXay3aw4LlRHPbjdfrhHZ3ibxJwanCFo=.3d2d49ca-15c7-4c25-a6df-c29da688e526@github.com>
Message-ID: <9lfen3cWjfmhkHN70dWMzO9q410gF1VKZY0jVI3SMcI=.621802bd-8d16-4544-9867-575a380ffa86@github.com>

On Mon, 11 Oct 2021 08:51:22 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-18+18

There known issues remaining with this merge: 

- [JDK-8274973](https://bugs.openjdk.java.net/browse/JDK-8274973)
- [JDK-8274972](https://bugs.openjdk.java.net/browse/JDK-8274972)
- [JDK-8274950](https://bugs.openjdk.java.net/browse/JDK-8274950)

Includes the following test failures:
- compiler/valhalla/inlinetypes/TestLWorld.java
- compiler/c2/irTests/TestPostParseCallDevirtualization.java
- compiler/valhalla/inlinetypes/TestArrays.java
- valhalla/valuetypes/ValueArray.java

Fixes to come post integration

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

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


From dsimms at openjdk.java.net  Mon Oct 11 10:35:09 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 11 Oct 2021 10:35:09 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <sVhlPTB0JmlxXay3aw4LlRHPbjdfrhHZ3ibxJwanCFo=.3d2d49ca-15c7-4c25-a6df-c29da688e526@github.com>
References: <sVhlPTB0JmlxXay3aw4LlRHPbjdfrhHZ3ibxJwanCFo=.3d2d49ca-15c7-4c25-a6df-c29da688e526@github.com>
Message-ID: <-DDMdYKt68lWe61Yy8NUiSiwJfRpNy8002ZFCgatuBo=.a77141c2-ac67-4d3c-9b75-e321216039dd@github.com>

> Merge jdk-18+18

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1272 commits:

 - Merge error
 - Merge tag 'jdk-18+18' into lworld_merge_jdk_20210921
   
   Added tag jdk-18+18 for changeset 9945f7a0
   
   # Conflicts:
   #	src/hotspot/share/services/heapDumper.cpp
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
   #	test/hotspot/jtreg/ProblemList.txt
 - Merge branch 'openjdk:lworld' into lworld_merge_jdk_20210921
 - 8274792: [lworld] Final fields should be flattened
   
   Reviewed-by: thartmann
 - assert(t->meet(t0) == t) failed: Not monotonic fix
 - type.[ch]pp merge
 - Merge branch 'openjdk:lworld' into lworld_merge_jdk_20210921
 - 8273360: [lworld] Invoking a reflection-generated constructor for primitive class gives InstantiationError
   
   Reviewed-by: mchung
 - 8273018: [lworld] Property annotation propagation to <init> lacks in primitive records
   8273202: [lworld] MethodParameters are not generated for factories for primitive records
   
   Reviewed-by: sadayapalam
 - Adjust problem list for initial aarch64 testing
 - ... and 1262 more: https://git.openjdk.java.net/valhalla/compare/9945f7a0...216bef67

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

Changes: https://git.openjdk.java.net/valhalla/pull/559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=559&range=01
  Stats: 157936 lines in 1513 files changed: 149530 ins; 1892 del; 6514 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/559/head:pull/559

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


From dsimms at openjdk.java.net  Mon Oct 11 10:35:12 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 11 Oct 2021 10:35:12 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <sVhlPTB0JmlxXay3aw4LlRHPbjdfrhHZ3ibxJwanCFo=.3d2d49ca-15c7-4c25-a6df-c29da688e526@github.com>
References: <sVhlPTB0JmlxXay3aw4LlRHPbjdfrhHZ3ibxJwanCFo=.3d2d49ca-15c7-4c25-a6df-c29da688e526@github.com>
Message-ID: <2RCkqG6RkqCyj_EYufLVinLINig1co71qiGnb4cqg8U=.e88d618e-77e1-468d-bc5a-bb0d64168eb3@github.com>

On Mon, 11 Oct 2021 08:51:22 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-18+18

This pull request has now been integrated.

Changeset: cb080234
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/cb080234f25f77f24c67d5f62b89a7b0908bf097
Stats:     60525 lines in 1999 files changed: 38976 ins; 11572 del; 9977 mod

Merge jdk

Merge jdk-18+18

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

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


From roland at openjdk.java.net  Wed Oct 13 07:37:27 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 13 Oct 2021 07:37:27 GMT
Subject: [lworld] RFR: 8275195: [lworld] Revisit use of TypePtr::meet_aryptr()
 after merge
Message-ID: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>

I tried to move the logic that I added to TypeAryKlassPtr into
meet_aryptr() where it's shared between TypeAryPtr and
TypeAryKlassPtr. When running tests, I ran into a failure that I fixed
by making the element klass of an array of nullable inline types
to be non constant similar to this logic:

    // Even if MyValue is exact, [LMyValue is not exact due to [QMyValue <: [LMyValue.
    bool xk = etype->klass_is_exact() && (!etype->is_inlinetypeptr() || null_free);

in TypeOopPtr::make_from_klass_common().

Actually, shouldn't the element type be non exact in the TypeAryPtr
case too?

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

Commit messages:
 - fix

Changes: https://git.openjdk.java.net/valhalla/pull/560/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=560&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275195
  Stats: 51 lines in 3 files changed: 16 ins; 11 del; 24 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/560.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/560/head:pull/560

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


From thartmann at openjdk.java.net  Wed Oct 13 12:27:32 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 13 Oct 2021 12:27:32 GMT
Subject: [lworld] RFR: 8275220: [lworld] Various compiler code cleanups and
 refactoring
Message-ID: <zz9HgXmY5kTF-5cjhaarJuLyl6_c7InlCSZ6G4eyhZY=.c8816527-7b45-474f-a2e8-83afe870bfb4@github.com>

This patch contains various code cleanups, refactorings and small improvements that I cherry-picked from the nullable Q-types prototype work.

Thanks,
Tobias

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

Commit messages:
 - Removed assert
 - 8275220: [lworld] Various compiler code cleanups and refactoring

Changes: https://git.openjdk.java.net/valhalla/pull/561/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=561&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275220
  Stats: 348 lines in 25 files changed: 73 ins; 183 del; 92 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/561.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/561/head:pull/561

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


From thartmann at openjdk.java.net  Wed Oct 13 12:41:38 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 13 Oct 2021 12:41:38 GMT
Subject: [lworld] RFR: 8275220: [lworld] Various compiler code cleanups and
 refactoring [v2]
In-Reply-To: <zz9HgXmY5kTF-5cjhaarJuLyl6_c7InlCSZ6G4eyhZY=.c8816527-7b45-474f-a2e8-83afe870bfb4@github.com>
References: <zz9HgXmY5kTF-5cjhaarJuLyl6_c7InlCSZ6G4eyhZY=.c8816527-7b45-474f-a2e8-83afe870bfb4@github.com>
Message-ID: <47h-BNjTIOmW1XkfhehMVaKo_ZutR8WcR9TX1ot0ZAU=.63794050-c06e-423e-be74-af70d7c325c5@github.com>

> This patch contains various code cleanups, refactorings and small improvements that I cherry-picked from the nullable Q-types prototype work.
> 
> Thanks,
> Tobias

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

  Restore accidentally deleted code

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/561/files
  - new: https://git.openjdk.java.net/valhalla/pull/561/files/7f3a3266..b1b70765

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=561&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=561&range=00-01

  Stats: 14 lines in 1 file changed: 8 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/561.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/561/head:pull/561

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


From thartmann at openjdk.java.net  Wed Oct 13 13:12:02 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 13 Oct 2021 13:12:02 GMT
Subject: [lworld] RFR: 8275195: [lworld] Revisit use of
 TypePtr::meet_aryptr() after merge
In-Reply-To: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
References: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
Message-ID: <54pHobldeJQxedp-BGZA7PIDCxS6KZW9FprQPaAkZlc=.c8404095-2a8c-473e-b3a3-ab5c51b31840@github.com>

On Wed, 13 Oct 2021 07:30:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Actually, shouldn't the element type be non exact in the TypeAryPtr case too?

Yes, I think so.

Just noticed this code you added previously in `TypeAryKlassPtr::make`:

    // An object array can't be flat or null-free if the klass is exact
    not_flat = true;
    if (!null_free) {
      not_null_free = true;
    }


How can it happen that `null_free` is true?

src/hotspot/share/opto/type.cpp line 5948:

> 5946:     const TypeKlassPtr *etype = TypeKlassPtr::make(eklass)->cast_to_exactness(false);
> 5947: 
> 5948:     if (etype->klass_is_exact() && etype->isa_instklassptr() && etype->is_instklassptr()->klass()->is_inlinetype() && !null_free) {

Please add a comment similar to the other places where we do this.

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

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


From roland at openjdk.java.net  Wed Oct 13 13:52:07 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 13 Oct 2021 13:52:07 GMT
Subject: [lworld] RFR: 8275195: [lworld] Revisit use of
 TypePtr::meet_aryptr() after merge
In-Reply-To: <54pHobldeJQxedp-BGZA7PIDCxS6KZW9FprQPaAkZlc=.c8404095-2a8c-473e-b3a3-ab5c51b31840@github.com>
References: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
 <54pHobldeJQxedp-BGZA7PIDCxS6KZW9FprQPaAkZlc=.c8404095-2a8c-473e-b3a3-ab5c51b31840@github.com>
Message-ID: <6gszy1_j-5xyy2ykaja5Bak7gsLd-Jy9pSGNEl-tOfM=.861e2b13-2cb0-4324-a08a-5573395ddcc8@github.com>

On Wed, 13 Oct 2021 13:09:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> > Actually, shouldn't the element type be non exact in the TypeAryPtr case too?
> 
> Yes, I think so.

Do you want me to take care of it in this change?

> Just noticed this code you added previously in `TypeAryKlassPtr::make`:
> 
> ```
>     // An object array can't be flat or null-free if the klass is exact
>     not_flat = true;
>     if (!null_free) {
>       not_null_free = true;
>     }
> ```
> 
> How can it happen that `null_free` is true?

Right above:


bool null_free = k->is_array_klass() && k->as_array_klass()->is_elem_null_free();

is that not correct?

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

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


From ngasson at openjdk.java.net  Thu Oct 14 06:13:16 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 14 Oct 2021 06:13:16 GMT
Subject: [lworld] RFR: 8274131: [lworld] [aarch64]
 ClassInitializationFailuresTest.java stop: klass not initialized
Message-ID: <ppLtNHYcW4cl0mPnRaFVuh7pVp3s8S9wdWwn-OAlU0U=.1c46c7d6-1a0c-445a-a2ef-b920b5db1ae8@github.com>

This check was removed on x86 as part of JDK-8273650.

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

Commit messages:
 - 8274131: [lworld] [aarch64] ClassInitializationFailuresTest.java stop: klass not initialized

Changes: https://git.openjdk.java.net/valhalla/pull/562/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=562&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274131
  Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/562.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/562/head:pull/562

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


From thartmann at openjdk.java.net  Thu Oct 14 06:25:15 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 14 Oct 2021 06:25:15 GMT
Subject: [lworld] RFR: 8275195: [lworld] Revisit use of
 TypePtr::meet_aryptr() after merge
In-Reply-To: <6gszy1_j-5xyy2ykaja5Bak7gsLd-Jy9pSGNEl-tOfM=.861e2b13-2cb0-4324-a08a-5573395ddcc8@github.com>
References: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
 <54pHobldeJQxedp-BGZA7PIDCxS6KZW9FprQPaAkZlc=.c8404095-2a8c-473e-b3a3-ab5c51b31840@github.com>
 <6gszy1_j-5xyy2ykaja5Bak7gsLd-Jy9pSGNEl-tOfM=.861e2b13-2cb0-4324-a08a-5573395ddcc8@github.com>
Message-ID: <lLsAHoj5hXxWZpocusO676_FabZqxdEm0ZNA01NidOk=.b0299234-4be7-409d-928c-e98f0021b71a@github.com>

On Wed, 13 Oct 2021 13:49:17 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Do you want me to take care of it in this change?

Yes, that would be great.

> is that not correct?

I'm a bit confused by this logic:
https://github.com/openjdk/valhalla/blob/cb080234f25f77f24c67d5f62b89a7b0908bf097/src/hotspot/share/opto/type.cpp#L5954-L5964

 `not_flat` is supposed to be true iff we know that the array can never be flat. However, it's initialized with `!k->is_flat_array_klass()` which does **not** mean that the array can never be flat. It could be an object array which can be flat if the element type is not exact. Also not null-free should imply not flat. In general, we can deduce that an array is not flat if (1) `!UseFlatArray`, (2) the array is not null-free or (3) the element type is an inline type that is not flattened in arrays.

Or am I missing something?

I think this logic should be orthogonal to this:
https://github.com/openjdk/valhalla/blob/cb080234f25f77f24c67d5f62b89a7b0908bf097/src/hotspot/share/opto/type.cpp#L3607-L3611

Also, can we use an enum for `TypeAryKlassPtr::_null_free`? The tri-state via an int is confusing as well.

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

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


From thartmann at openjdk.java.net  Thu Oct 14 07:32:59 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 14 Oct 2021 07:32:59 GMT
Subject: [lworld] RFR: 8274131: [lworld] [aarch64]
 ClassInitializationFailuresTest.java stop: klass not initialized
In-Reply-To: <ppLtNHYcW4cl0mPnRaFVuh7pVp3s8S9wdWwn-OAlU0U=.1c46c7d6-1a0c-445a-a2ef-b920b5db1ae8@github.com>
References: <ppLtNHYcW4cl0mPnRaFVuh7pVp3s8S9wdWwn-OAlU0U=.1c46c7d6-1a0c-445a-a2ef-b920b5db1ae8@github.com>
Message-ID: <_EcbzGeqFDNyD6P2uagBwSC_jM0MFZdogAIFVCALoQ8=.9f867006-156c-4b1c-9f23-89605bc95c3b@github.com>

On Thu, 14 Oct 2021 06:08:05 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This check was removed on x86 as part of JDK-8273650.

Looks good.

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

Marked as reviewed by thartmann (Committer).

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


From ngasson at openjdk.java.net  Thu Oct 14 09:04:14 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 14 Oct 2021 09:04:14 GMT
Subject: [lworld] RFR: 8274131: [lworld] [aarch64]
 ClassInitializationFailuresTest.java stop: klass not initialized
In-Reply-To: <_EcbzGeqFDNyD6P2uagBwSC_jM0MFZdogAIFVCALoQ8=.9f867006-156c-4b1c-9f23-89605bc95c3b@github.com>
References: <ppLtNHYcW4cl0mPnRaFVuh7pVp3s8S9wdWwn-OAlU0U=.1c46c7d6-1a0c-445a-a2ef-b920b5db1ae8@github.com>
 <_EcbzGeqFDNyD6P2uagBwSC_jM0MFZdogAIFVCALoQ8=.9f867006-156c-4b1c-9f23-89605bc95c3b@github.com>
Message-ID: <M44BLVEf_BZu6eJWJBj86h8_bdGtxfUd_5-obF9O1aU=.0e0fbd30-8b65-4112-ba20-b522991525b1@github.com>

On Thu, 14 Oct 2021 07:30:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This check was removed on x86 as part of JDK-8273650.
>
> Looks good.

Thanks @TobiHartmann !

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

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


From roland at openjdk.java.net  Thu Oct 14 09:04:23 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 14 Oct 2021 09:04:23 GMT
Subject: [lworld] RFR: 8274972: [lworld] TestLWorld.test151() fails with IR
 verification errors
Message-ID: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>

The test failure is caused by this check:
bool LateInlineVirtualCallGenerator::do_late_inline_check(Compile* C, JVMState* jvms) {
  // Method handle linker case is handled in CallDynamicJavaNode::Ideal().
  // Unless inlining is performed, _override_symbolic_info bit will be set in DirectCallGenerator::generate().
  // Implicit receiver null checks introduce problems when exception states are combined.
  Node* receiver = jvms->map()->argument(jvms, 0);
  const Type* recv_type = C->initial_gvn()->type(receiver);
  if (recv_type->maybe_null()) {
    return false;
  }
  
That code came with the recent merge. receiver should be not null
(it's a InlineTypePtrNode) but it's not. The InlineTypePtrNode is
created when pushed down through Phis. The fix I propose is to set the
type of the phi that's the Oop input to InlineTypeBase to non null
when it's created if it's observed that all InlineTypeBase nodes
encountered when following Phi inputs are non null.

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

Commit messages:
 - fix

Changes: https://git.openjdk.java.net/valhalla/pull/563/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=563&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274972
  Stats: 19 lines in 4 files changed: 10 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/563.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/563/head:pull/563

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


From ngasson at openjdk.java.net  Thu Oct 14 09:12:09 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 14 Oct 2021 09:12:09 GMT
Subject: [lworld] Integrated: 8274131: [lworld] [aarch64]
 ClassInitializationFailuresTest.java stop: klass not initialized
In-Reply-To: <ppLtNHYcW4cl0mPnRaFVuh7pVp3s8S9wdWwn-OAlU0U=.1c46c7d6-1a0c-445a-a2ef-b920b5db1ae8@github.com>
References: <ppLtNHYcW4cl0mPnRaFVuh7pVp3s8S9wdWwn-OAlU0U=.1c46c7d6-1a0c-445a-a2ef-b920b5db1ae8@github.com>
Message-ID: <tojndLo9bXSMmfh3EETQl9Dddmm9Os4P3uTdYcOEilQ=.122d194c-7b64-464b-b0de-6217f835e753@github.com>

On Thu, 14 Oct 2021 06:08:05 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This check was removed on x86 as part of JDK-8273650.

This pull request has now been integrated.

Changeset: 7de67f1e
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/7de67f1ea57a7eed5f99467ea3d52841c1c3f466
Stats:     11 lines in 1 file changed: 0 ins; 11 del; 0 mod

8274131: [lworld] [aarch64] ClassInitializationFailuresTest.java stop: klass not initialized

Reviewed-by: thartmann

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

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


From thartmann at openjdk.java.net  Thu Oct 14 09:22:08 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 14 Oct 2021 09:22:08 GMT
Subject: [lworld] Integrated: 8275220: [lworld] Various compiler code cleanups
 and refactoring
In-Reply-To: <zz9HgXmY5kTF-5cjhaarJuLyl6_c7InlCSZ6G4eyhZY=.c8816527-7b45-474f-a2e8-83afe870bfb4@github.com>
References: <zz9HgXmY5kTF-5cjhaarJuLyl6_c7InlCSZ6G4eyhZY=.c8816527-7b45-474f-a2e8-83afe870bfb4@github.com>
Message-ID: <s2tmtZENBNwnG54GIXnf8F3lznTbI_zh51oZpQx90DA=.743bdc76-e8e6-4d5c-ad35-2150601dd420@github.com>

On Wed, 13 Oct 2021 12:20:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This patch contains various code cleanups, refactorings and small improvements that I cherry-picked from the nullable Q-types prototype work.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 68265657
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/68265657bf1901965fafba3c258d39d202e1941a
Stats:     349 lines in 25 files changed: 75 ins; 177 del; 97 mod

8275220: [lworld] Various compiler code cleanups and refactoring

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

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


From thartmann at openjdk.java.net  Thu Oct 14 09:47:13 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 14 Oct 2021 09:47:13 GMT
Subject: [lworld] RFR: 8274972: [lworld] TestLWorld.test151() fails with IR
 verification errors
In-Reply-To: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
References: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
Message-ID: <W46Zyfnp52b6BTFl8BNEE2PuS2eHiPoqybhDwwr0NgI=.041bbc7d-6630-4e57-a6fb-7e53e01e92e4@github.com>

On Thu, 14 Oct 2021 08:59:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The test failure is caused by this check:
> bool LateInlineVirtualCallGenerator::do_late_inline_check(Compile* C, JVMState* jvms) {
>   // Method handle linker case is handled in CallDynamicJavaNode::Ideal().
>   // Unless inlining is performed, _override_symbolic_info bit will be set in DirectCallGenerator::generate().
>   // Implicit receiver null checks introduce problems when exception states are combined.
>   Node* receiver = jvms->map()->argument(jvms, 0);
>   const Type* recv_type = C->initial_gvn()->type(receiver);
>   if (recv_type->maybe_null()) {
>     return false;
>   }
>   
> That code came with the recent merge. receiver should be not null
> (it's a InlineTypePtrNode) but it's not. The InlineTypePtrNode is
> created when pushed down through Phis. The fix I propose is to set the
> type of the phi that's the Oop input to InlineTypeBase to non null
> when it's created if it's observed that all InlineTypeBase nodes
> encountered when following Phi inputs are non null.

Looks good. Just wondering, why does IGVN not update the type of the Phi accordingly?

Please re-enable the test, I've just disabled it with https://github.com/openjdk/valhalla/commit/68265657bf1901965fafba3c258d39d202e1941a#diff-4d835d6d5e9844534a306405cf02e01b816b80a13a2e911d2f37fd38ecb2ac69R4123

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

Marked as reviewed by thartmann (Committer).

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


From roland at openjdk.java.net  Thu Oct 14 09:52:06 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 14 Oct 2021 09:52:06 GMT
Subject: [lworld] RFR: 8274972: [lworld] TestLWorld.test151() fails with IR
 verification errors
In-Reply-To: <W46Zyfnp52b6BTFl8BNEE2PuS2eHiPoqybhDwwr0NgI=.041bbc7d-6630-4e57-a6fb-7e53e01e92e4@github.com>
References: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
 <W46Zyfnp52b6BTFl8BNEE2PuS2eHiPoqybhDwwr0NgI=.041bbc7d-6630-4e57-a6fb-7e53e01e92e4@github.com>
Message-ID: <ufIRXphkjy2yd3yfCZNsn5HM5FURN651gegkher5Ans=.0a827d75-f944-4ae9-b755-aa2e88b57f2c@github.com>

On Thu, 14 Oct 2021 09:44:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good. Just wondering, why does IGVN not update the type of the Phi accordingly?

The test has a loop so that would require CCP but the Phi is created after CCP.

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

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


From thartmann at openjdk.java.net  Thu Oct 14 10:04:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 14 Oct 2021 10:04:05 GMT
Subject: [lworld] RFR: 8274972: [lworld] TestLWorld.test151() fails with IR
 verification errors
In-Reply-To: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
References: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
Message-ID: <3oITvrUwohhnkO0j6XBkqrB6kQycGbGg0acL2v1GO7U=.dd892011-2b5d-4d83-ba23-f9bb84773651@github.com>

On Thu, 14 Oct 2021 08:59:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The test failure is caused by this check:
> bool LateInlineVirtualCallGenerator::do_late_inline_check(Compile* C, JVMState* jvms) {
>   // Method handle linker case is handled in CallDynamicJavaNode::Ideal().
>   // Unless inlining is performed, _override_symbolic_info bit will be set in DirectCallGenerator::generate().
>   // Implicit receiver null checks introduce problems when exception states are combined.
>   Node* receiver = jvms->map()->argument(jvms, 0);
>   const Type* recv_type = C->initial_gvn()->type(receiver);
>   if (recv_type->maybe_null()) {
>     return false;
>   }
>   
> That code came with the recent merge. receiver should be not null
> (it's a InlineTypePtrNode) but it's not. The InlineTypePtrNode is
> created when pushed down through Phis. The fix I propose is to set the
> type of the phi that's the Oop input to InlineTypeBase to non null
> when it's created if it's observed that all InlineTypeBase nodes
> encountered when following Phi inputs are non null.

Ah, right. Makes sense.

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

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


From thartmann at openjdk.java.net  Thu Oct 14 11:09:25 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 14 Oct 2021 11:09:25 GMT
Subject: [lworld] RFR: 8275276: [lworld] C2 compilation fails with assert
 "adr_type for memory phis only"
Message-ID: <cWtT5Fz7IuiL3qk6QUtP9GoSitf5gYoPff-hSWplWw0=.16e21868-d2fc-4974-8752-d1a7686fcd6c@github.com>

`PhiNode::verify_adr_type` fails with an assert because the phi has `Type::MEMORY` but `_adr_type` is not set. The phi is created when pushing bool/cmp pairs through a Phi in `PhaseIdealLoop::clone_iff` for Loop Unswitching:

![Screenshot from 2021-10-14 12-58-37](https://user-images.githubusercontent.com/5312595/137304712-c1450fbf-dcf9-4d83-a5f6-36db8abb1c09.png)

Is converted to:

![Screenshot from 2021-10-14 12-59-00](https://user-images.githubusercontent.com/5312595/137304754-f686d862-4be4-4438-9d10-c7c6bca95f89.png)

The code does not correctly handle `FlatArrayCheckNodes` which have a memory input as left input. The fix is to properly set the `_adr_type` in that case.

Best regards,
Tobias

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

Commit messages:
 - 8275276: [lworld] C2 compilation fails with assert "adr_type for memory phis only"

Changes: https://git.openjdk.java.net/valhalla/pull/564/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=564&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275276
  Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/564.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/564/head:pull/564

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


From thartmann at openjdk.java.net  Thu Oct 14 11:55:45 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 14 Oct 2021 11:55:45 GMT
Subject: [lworld] RFR: 8273594: [lworld] JITs need to properly handle
 static inline type field with unloaded type [v5]
In-Reply-To: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
References: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
Message-ID: <5v2ai-3wrIOskIFd5X1ncHpvLzqQjpUofNU1FrS2wSI=.4ac5cf66-abc8-4916-9db6-051b59166c21@github.com>

> Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.
> 
> I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.
> 
> I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.
> 
> Thanks,
> Tobias

Tobias Hartmann 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 ten additional commits since the last revision:

 - Test fix
 - Merge branch 'lworld' into JDK-8273594
 - Fix
 - Remove -Xint from CircularityTest
 - Merge branch 'lworld' into JDK-8273594
 - Check for uninitialized class
 - Deoptimization does no longer support symbolic names for the class index, use a simple trap instead
 - Don't modify do_Deoptimize
 - 8273594: [lworld] JITs need to properly handle static inline type field with unloaded type

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/551/files
  - new: https://git.openjdk.java.net/valhalla/pull/551/files/35a1c2a7..4f2a467a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=551&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=551&range=03-04

  Stats: 62387 lines in 2034 files changed: 40281 ins; 11984 del; 10122 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/551.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/551/head:pull/551

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


From fparain at openjdk.java.net  Thu Oct 14 20:47:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 14 Oct 2021 20:47:22 GMT
Subject: [lworld] RFR: 8273594: [lworld] JITs need to properly handle
 static inline type field with unloaded type [v5]
In-Reply-To: <5v2ai-3wrIOskIFd5X1ncHpvLzqQjpUofNU1FrS2wSI=.4ac5cf66-abc8-4916-9db6-051b59166c21@github.com>
References: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
 <5v2ai-3wrIOskIFd5X1ncHpvLzqQjpUofNU1FrS2wSI=.4ac5cf66-abc8-4916-9db6-051b59166c21@github.com>
Message-ID: <UsMaYpZpi_UbIe3bd-RYZ28hQpf7XML8OKyE6rHLOhI=.b1364515-8c05-44e8-af2c-ad85532ae0fd@github.com>

On Thu, 14 Oct 2021 11:55:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.
>> 
>> I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.
>> 
>> I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann 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 ten additional commits since the last revision:
> 
>  - Test fix
>  - Merge branch 'lworld' into JDK-8273594
>  - Fix
>  - Remove -Xint from CircularityTest
>  - Merge branch 'lworld' into JDK-8273594
>  - Check for uninitialized class
>  - Deoptimization does no longer support symbolic names for the class index, use a simple trap instead
>  - Don't modify do_Deoptimize
>  - 8273594: [lworld] JITs need to properly handle static inline type field with unloaded type

C1 changes look good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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


From thartmann at openjdk.java.net  Fri Oct 15 06:00:17 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 15 Oct 2021 06:00:17 GMT
Subject: [lworld] Integrated: 8275276: [lworld] C2 compilation fails with
 assert "adr_type for memory phis only"
In-Reply-To: <cWtT5Fz7IuiL3qk6QUtP9GoSitf5gYoPff-hSWplWw0=.16e21868-d2fc-4974-8752-d1a7686fcd6c@github.com>
References: <cWtT5Fz7IuiL3qk6QUtP9GoSitf5gYoPff-hSWplWw0=.16e21868-d2fc-4974-8752-d1a7686fcd6c@github.com>
Message-ID: <pcouVZe1LWPmCrQxc2V_-ZBDpMGtvuGu9e2-KrCYmNs=.a56a506c-3ee0-48cc-96f3-e913c8974f5c@github.com>

On Thu, 14 Oct 2021 11:02:52 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `PhiNode::verify_adr_type` fails with an assert because the phi has `Type::MEMORY` but `_adr_type` is not set. The phi is created when pushing bool/cmp pairs through a Phi in `PhaseIdealLoop::clone_iff` for Loop Unswitching:
> 
> ![Screenshot from 2021-10-14 12-58-37](https://user-images.githubusercontent.com/5312595/137304712-c1450fbf-dcf9-4d83-a5f6-36db8abb1c09.png)
> 
> Is converted to:
> 
> ![Screenshot from 2021-10-14 12-59-00](https://user-images.githubusercontent.com/5312595/137304754-f686d862-4be4-4438-9d10-c7c6bca95f89.png)
> 
> The code does not correctly handle `FlatArrayCheckNodes` which have a memory input as left input. The fix is to properly set the `_adr_type` in that case.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: cff488b1
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/cff488b15374144d959865e7a58244fea2dd9c92
Stats:     75 lines in 2 files changed: 73 ins; 0 del; 2 mod

8275276: [lworld] C2 compilation fails with assert "adr_type for memory phis only"

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

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


From thartmann at openjdk.java.net  Fri Oct 15 06:02:12 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 15 Oct 2021 06:02:12 GMT
Subject: [lworld] RFR: 8273594: [lworld] JITs need to properly handle
 static inline type field with unloaded type [v5]
In-Reply-To: <5v2ai-3wrIOskIFd5X1ncHpvLzqQjpUofNU1FrS2wSI=.4ac5cf66-abc8-4916-9db6-051b59166c21@github.com>
References: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
 <5v2ai-3wrIOskIFd5X1ncHpvLzqQjpUofNU1FrS2wSI=.4ac5cf66-abc8-4916-9db6-051b59166c21@github.com>
Message-ID: <wcsJoiW4FoqCTE4d6DBvkypZ0O1RH_cCGVok7HelnB0=.8c279032-a7bc-49d6-86e0-c5154e373b12@github.com>

On Thu, 14 Oct 2021 11:55:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.
>> 
>> I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.
>> 
>> I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann 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 ten additional commits since the last revision:
> 
>  - Test fix
>  - Merge branch 'lworld' into JDK-8273594
>  - Fix
>  - Remove -Xint from CircularityTest
>  - Merge branch 'lworld' into JDK-8273594
>  - Check for uninitialized class
>  - Deoptimization does no longer support symbolic names for the class index, use a simple trap instead
>  - Don't modify do_Deoptimize
>  - 8273594: [lworld] JITs need to properly handle static inline type field with unloaded type

Thanks, Fred!

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

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


From thartmann at openjdk.java.net  Fri Oct 15 06:02:13 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 15 Oct 2021 06:02:13 GMT
Subject: [lworld] Integrated: 8273594: [lworld] JITs need to properly handle
 static inline type field with unloaded type
In-Reply-To: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
References: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
Message-ID: <2WTR0hXpvvE_N7LwEeDfk0xuIy99ZZRfsEmpPKBvhPQ=.13f501cb-a03e-4aec-b3f3-2bcc4574f2de@github.com>

On Fri, 10 Sep 2021 11:19:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.
> 
> I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.
> 
> I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 902a1577
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/902a15773118364db4ea38c2cc9c5f93f49c1394
Stats:     264 lines in 7 files changed: 234 ins; 9 del; 21 mod

8273594: [lworld] JITs need to properly handle static inline type field with unloaded type

Reviewed-by: fparain

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

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


From roland at openjdk.java.net  Fri Oct 15 10:26:37 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 15 Oct 2021 10:26:37 GMT
Subject: [lworld] RFR: 8274972: [lworld] TestLWorld.test151() fails with IR
 verification errors [v2]
In-Reply-To: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
References: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
Message-ID: <dsjGwA-xme3Y648EojO6DTfq0NiYpmN61rea5pct87g=.c609a229-8b72-499d-a9d2-3db6e28eb9a1@github.com>

> The test failure is caused by this check:
> bool LateInlineVirtualCallGenerator::do_late_inline_check(Compile* C, JVMState* jvms) {
>   // Method handle linker case is handled in CallDynamicJavaNode::Ideal().
>   // Unless inlining is performed, _override_symbolic_info bit will be set in DirectCallGenerator::generate().
>   // Implicit receiver null checks introduce problems when exception states are combined.
>   Node* receiver = jvms->map()->argument(jvms, 0);
>   const Type* recv_type = C->initial_gvn()->type(receiver);
>   if (recv_type->maybe_null()) {
>     return false;
>   }
>   
> That code came with the recent merge. receiver should be not null
> (it's a InlineTypePtrNode) but it's not. The InlineTypePtrNode is
> created when pushed down through Phis. The fix I propose is to set the
> type of the phi that's the Oop input to InlineTypeBase to non null
> when it's created if it's observed that all InlineTypeBase nodes
> encountered when following Phi inputs are non null.

Roland Westrelin 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 three additional commits since the last revision:

 - revised fix
 - Merge branch 'lworld' into JDK-8274972
 - fix

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/563/files
  - new: https://git.openjdk.java.net/valhalla/pull/563/files/ab6031b9..098d4ae9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=563&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=563&range=00-01

  Stats: 731 lines in 36 files changed: 390 ins; 200 del; 141 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/563.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/563/head:pull/563

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


From roland at openjdk.java.net  Fri Oct 15 10:26:38 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 15 Oct 2021 10:26:38 GMT
Subject: [lworld] RFR: 8274972: [lworld] TestLWorld.test151() fails with IR
 verification errors
In-Reply-To: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
References: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
Message-ID: <0uR_xA3AFXRizZEjCnfmsWj2kY5COrmHqQE2Me-z-sQ=.58731d28-8915-4721-89fa-256abe001201@github.com>

On Thu, 14 Oct 2021 08:59:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The test failure is caused by this check:
> bool LateInlineVirtualCallGenerator::do_late_inline_check(Compile* C, JVMState* jvms) {
>   // Method handle linker case is handled in CallDynamicJavaNode::Ideal().
>   // Unless inlining is performed, _override_symbolic_info bit will be set in DirectCallGenerator::generate().
>   // Implicit receiver null checks introduce problems when exception states are combined.
>   Node* receiver = jvms->map()->argument(jvms, 0);
>   const Type* recv_type = C->initial_gvn()->type(receiver);
>   if (recv_type->maybe_null()) {
>     return false;
>   }
>   
> That code came with the recent merge. receiver should be not null
> (it's a InlineTypePtrNode) but it's not. The InlineTypePtrNode is
> created when pushed down through Phis. The fix I propose is to set the
> type of the phi that's the Oop input to InlineTypeBase to non null
> when it's created if it's observed that all InlineTypeBase nodes
> encountered when following Phi inputs are non null.

Actually that fix doesn't work. I updated it to accumulate the IsInit input instead of the Oop input.

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

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


From thartmann at openjdk.java.net  Fri Oct 15 13:14:25 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 15 Oct 2021 13:14:25 GMT
Subject: [lworld] RFR: 8275331: [lworld] TestArrays.java fails IR verification
 on aarch64
Message-ID: <Wy3AX-m3SEA70-CdvewMmcaalw9hnZ1IrOD8cERTSCA=.c82ebc3f-c87c-465b-ab60-9584f7ab1017@github.com>

IR verification fails after the recent merge with mainline because the fix for [JDK-8273825](https://bugs.openjdk.java.net/browse/JDK-8273825) needs to be applied to Valhalla specific matching rules.

I also problem listed `TestPostParseCallDevirtualization` until [JDK-8274973](https://bugs.openjdk.java.net/browse/JDK-8274973) is fixed.

Best regards,
Tobias

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

Commit messages:
 - 8275331: [lworld] TestArrays.java fails IR verification on aarch64

Changes: https://git.openjdk.java.net/valhalla/pull/565/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=565&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275331
  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/565.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/565/head:pull/565

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


From thartmann at openjdk.java.net  Fri Oct 15 13:18:12 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 15 Oct 2021 13:18:12 GMT
Subject: [lworld] Integrated: 8275331: [lworld] TestArrays.java fails IR
 verification on aarch64
In-Reply-To: <Wy3AX-m3SEA70-CdvewMmcaalw9hnZ1IrOD8cERTSCA=.c82ebc3f-c87c-465b-ab60-9584f7ab1017@github.com>
References: <Wy3AX-m3SEA70-CdvewMmcaalw9hnZ1IrOD8cERTSCA=.c82ebc3f-c87c-465b-ab60-9584f7ab1017@github.com>
Message-ID: <VTp8W8LjN7fkDqsRLJYJ08gFh0EwMTGAQ7Sosj1kU6E=.d4dadc5d-92d8-43a3-891c-d6966925c494@github.com>

On Fri, 15 Oct 2021 13:07:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> IR verification fails after the recent merge with mainline because the fix for [JDK-8273825](https://bugs.openjdk.java.net/browse/JDK-8273825) needs to be applied to Valhalla specific matching rules.
> 
> I also problem listed `TestPostParseCallDevirtualization` until [JDK-8274973](https://bugs.openjdk.java.net/browse/JDK-8274973) is fixed.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 0868f386
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0868f38696faeaab87ac8d65dc5d6ca76c384ebe
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8275331: [lworld] TestArrays.java fails IR verification on aarch64

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

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


From thartmann at openjdk.java.net  Mon Oct 18 06:03:23 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 18 Oct 2021 06:03:23 GMT
Subject: [lworld] RFR: 8274972: [lworld] TestLWorld.test151() fails with IR
 verification errors [v2]
In-Reply-To: <dsjGwA-xme3Y648EojO6DTfq0NiYpmN61rea5pct87g=.c609a229-8b72-499d-a9d2-3db6e28eb9a1@github.com>
References: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
 <dsjGwA-xme3Y648EojO6DTfq0NiYpmN61rea5pct87g=.c609a229-8b72-499d-a9d2-3db6e28eb9a1@github.com>
Message-ID: <tpWTwrjVtoNNOAIjXVkBQ6kDUCjlZpMoPwboKRaQ5uo=.97ef5a89-ebe3-42f1-b00d-387743746aae@github.com>

On Fri, 15 Oct 2021 10:26:37 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The test failure is caused by this check:
>> bool LateInlineVirtualCallGenerator::do_late_inline_check(Compile* C, JVMState* jvms) {
>>   // Method handle linker case is handled in CallDynamicJavaNode::Ideal().
>>   // Unless inlining is performed, _override_symbolic_info bit will be set in DirectCallGenerator::generate().
>>   // Implicit receiver null checks introduce problems when exception states are combined.
>>   Node* receiver = jvms->map()->argument(jvms, 0);
>>   const Type* recv_type = C->initial_gvn()->type(receiver);
>>   if (recv_type->maybe_null()) {
>>     return false;
>>   }
>>   
>> That code came with the recent merge. receiver should be not null
>> (it's a InlineTypePtrNode) but it's not. The InlineTypePtrNode is
>> created when pushed down through Phis. The fix I propose is to set the
>> type of the phi that's the Oop input to InlineTypeBase to non null
>> when it's created if it's observed that all InlineTypeBase nodes
>> encountered when following Phi inputs are non null.
>
> Roland Westrelin 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 three additional commits since the last revision:
> 
>  - revised fix
>  - Merge branch 'lworld' into JDK-8274972
>  - fix

Looks good to me. Please file a bug for enabling the assert.

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

Marked as reviewed by thartmann (Committer).

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


From roland at openjdk.java.net  Mon Oct 18 09:15:14 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 18 Oct 2021 09:15:14 GMT
Subject: [lworld] Integrated: 8274972: [lworld] TestLWorld.test151() fails with
 IR verification errors
In-Reply-To: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
References: <Cdvjmf7BXjYHDD25dlz7n15bMrpeZ4pBqNRMuwt52b0=.7581d61e-ec7f-4632-9cf7-25508dcee0b4@github.com>
Message-ID: <RfcBLc5g_YVdZJCyyF2dIT6tgzsjbinc0G89_o1EbBY=.f5a4e817-ee5a-4d67-a25c-174fd793cbb0@github.com>

On Thu, 14 Oct 2021 08:59:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The test failure is caused by this check:
> bool LateInlineVirtualCallGenerator::do_late_inline_check(Compile* C, JVMState* jvms) {
>   // Method handle linker case is handled in CallDynamicJavaNode::Ideal().
>   // Unless inlining is performed, _override_symbolic_info bit will be set in DirectCallGenerator::generate().
>   // Implicit receiver null checks introduce problems when exception states are combined.
>   Node* receiver = jvms->map()->argument(jvms, 0);
>   const Type* recv_type = C->initial_gvn()->type(receiver);
>   if (recv_type->maybe_null()) {
>     return false;
>   }
>   
> That code came with the recent merge. receiver should be not null
> (it's a InlineTypePtrNode) but it's not. The InlineTypePtrNode is
> created when pushed down through Phis. The fix I propose is to set the
> type of the phi that's the Oop input to InlineTypeBase to non null
> when it's created if it's observed that all InlineTypeBase nodes
> encountered when following Phi inputs are non null.

This pull request has now been integrated.

Changeset: 715b8330
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/715b8330bb4d3ad533123aaf8e01777e4b4d01c6
Stats:     39 lines in 5 files changed: 18 ins; 3 del; 18 mod

8274972: [lworld] TestLWorld.test151() fails with IR verification errors

Reviewed-by: thartmann

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

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


From roland at openjdk.java.net  Mon Oct 18 09:15:46 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 18 Oct 2021 09:15:46 GMT
Subject: [lworld] RFR: 8275195: [lworld] Revisit use of
 TypePtr::meet_aryptr() after merge [v2]
In-Reply-To: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
References: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
Message-ID: <BK2BlAJFcTWWEb9SCnHv5RjsXYwBOKk0CjyXLXN-0Oc=.2256a6ab-8b5b-4b76-af90-bce13d831003@github.com>

> I tried to move the logic that I added to TypeAryKlassPtr into
> meet_aryptr() where it's shared between TypeAryPtr and
> TypeAryKlassPtr. When running tests, I ran into a failure that I fixed
> by making the element klass of an array of nullable inline types
> to be non constant similar to this logic:
> 
>     // Even if MyValue is exact, [LMyValue is not exact due to [QMyValue <: [LMyValue.
>     bool xk = etype->klass_is_exact() && (!etype->is_inlinetypeptr() || null_free);
> 
> in TypeOopPtr::make_from_klass_common().
> 
> Actually, shouldn't the element type be non exact in the TypeAryPtr
> case too?

Roland Westrelin 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 three additional commits since the last revision:

 - review
 - Merge branch 'lworld' into HEAD
 - fix

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/560/files
  - new: https://git.openjdk.java.net/valhalla/pull/560/files/9f1ba5de..f760dcf2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=560&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=560&range=00-01

  Stats: 729 lines in 37 files changed: 391 ins; 202 del; 136 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/560.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/560/head:pull/560

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


From roland at openjdk.java.net  Mon Oct 18 09:15:47 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 18 Oct 2021 09:15:47 GMT
Subject: [lworld] RFR: 8275195: [lworld] Revisit use of
 TypePtr::meet_aryptr() after merge [v2]
In-Reply-To: <lLsAHoj5hXxWZpocusO676_FabZqxdEm0ZNA01NidOk=.b0299234-4be7-409d-928c-e98f0021b71a@github.com>
References: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
 <54pHobldeJQxedp-BGZA7PIDCxS6KZW9FprQPaAkZlc=.c8404095-2a8c-473e-b3a3-ab5c51b31840@github.com>
 <6gszy1_j-5xyy2ykaja5Bak7gsLd-Jy9pSGNEl-tOfM=.861e2b13-2cb0-4324-a08a-5573395ddcc8@github.com>
 <lLsAHoj5hXxWZpocusO676_FabZqxdEm0ZNA01NidOk=.b0299234-4be7-409d-928c-e98f0021b71a@github.com>
Message-ID: <cA-bT0_oEF-iBnAoIwZlbGxPRde5HWACdctuuqp4fLM=.a5fe3bee-a0a2-4ad8-af8a-71b1a87e5052@github.com>

On Thu, 14 Oct 2021 06:22:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I'm a bit confused by this logic:

I updated that logic after we discussed it offline.

> Also, can we use an enum for `TypeAryKlassPtr::_null_free`? The tri-state via an int is confusing as well.

I switched to a boolean as the tri-state variable doesn't appear to be needed after all.

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

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


From thartmann at openjdk.java.net  Mon Oct 18 11:00:18 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 18 Oct 2021 11:00:18 GMT
Subject: [lworld] RFR: 8275195: [lworld] Revisit use of
 TypePtr::meet_aryptr() after merge [v2]
In-Reply-To: <BK2BlAJFcTWWEb9SCnHv5RjsXYwBOKk0CjyXLXN-0Oc=.2256a6ab-8b5b-4b76-af90-bce13d831003@github.com>
References: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
 <BK2BlAJFcTWWEb9SCnHv5RjsXYwBOKk0CjyXLXN-0Oc=.2256a6ab-8b5b-4b76-af90-bce13d831003@github.com>
Message-ID: <JyzDvKMPhGywSVbwiU-SxBrOrS0RKcKNHgT53EL_kjs=.70e24e2b-71c7-489a-a7fa-dcf72c5d59e1@github.com>

On Mon, 18 Oct 2021 09:15:46 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I tried to move the logic that I added to TypeAryKlassPtr into
>> meet_aryptr() where it's shared between TypeAryPtr and
>> TypeAryKlassPtr. When running tests, I ran into a failure that I fixed
>> by making the element klass of an array of nullable inline types
>> to be non constant similar to this logic:
>> 
>>     // Even if MyValue is exact, [LMyValue is not exact due to [QMyValue <: [LMyValue.
>>     bool xk = etype->klass_is_exact() && (!etype->is_inlinetypeptr() || null_free);
>> 
>> in TypeOopPtr::make_from_klass_common().
>> 
>> Actually, shouldn't the element type be non exact in the TypeAryPtr
>> case too?
>
> Roland Westrelin 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 three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'lworld' into HEAD
>  - fix

That looks good to me.

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

Marked as reviewed by thartmann (Committer).

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


From roland at openjdk.java.net  Mon Oct 18 11:11:14 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 18 Oct 2021 11:11:14 GMT
Subject: [lworld] Integrated: 8275195: [lworld] Revisit use of
 TypePtr::meet_aryptr() after merge
In-Reply-To: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
References: <T-vi4mNT4X407cIsWmoBLNQLHMELMnxYPZR2tlzDlj8=.d3350ccd-b577-481f-ae07-b27ba2a14028@github.com>
Message-ID: <83BTJOIUKCMujZCOXNDDmHAX4OIz1G9XiEPFOGm5Um4=.fe3bb230-dcae-4f47-a6e3-48d4f38f203b@github.com>

On Wed, 13 Oct 2021 07:30:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> I tried to move the logic that I added to TypeAryKlassPtr into
> meet_aryptr() where it's shared between TypeAryPtr and
> TypeAryKlassPtr. When running tests, I ran into a failure that I fixed
> by making the element klass of an array of nullable inline types
> to be non constant similar to this logic:
> 
>     // Even if MyValue is exact, [LMyValue is not exact due to [QMyValue <: [LMyValue.
>     bool xk = etype->klass_is_exact() && (!etype->is_inlinetypeptr() || null_free);
> 
> in TypeOopPtr::make_from_klass_common().
> 
> Actually, shouldn't the element type be non exact in the TypeAryPtr
> case too?

This pull request has now been integrated.

Changeset: 31bbb950
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/31bbb950e3a9084d21e7abbbadf0089f8df2ed8b
Stats:     81 lines in 3 files changed: 25 ins; 16 del; 40 mod

8275195: [lworld] Revisit use of TypePtr::meet_aryptr() after merge

Reviewed-by: thartmann

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

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


From thartmann at openjdk.java.net  Tue Oct 19 11:32:25 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 19 Oct 2021 11:32:25 GMT
Subject: [lworld] RFR: 8274950: [lworld] LoadNode::Identity optimization should
 not skip casts
Message-ID: <Wbvdkg7hrrbkYpRnDDYhV5gWf_n_E7AwuYvZ3P1CaEY=.0fc81d0f-27e9-4aeb-9fc8-3ede7a02419a@github.com>

When implementing scalarization of nullable inline types with [JDK-8267665](https://bugs.openjdk.java.net/browse/JDK-8267665), I added code to skip cast nodes. This allows the `LoadNode::Identity` optimization to fold loads from `InlineTypePtrNodes` that are hidden behind casts. However, skipping casts is often not correct because not only do we potentially lose type information but the cast could also fail. In the reported case, we hit an assert because we are loading from an offset that does not correspond to a field in the inline type (because the cast would fail).

This patch handles cast nodes properly by pushing them up through the InlineTypePtrNode oop input.

Best regards,
Tobias

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

Commit messages:
 - 8274950: [lworld] LoadNode::Identity optimization should not skip casts

Changes: https://git.openjdk.java.net/valhalla/pull/566/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=566&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274950
  Stats: 115 lines in 6 files changed: 93 ins; 1 del; 21 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/566.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/566/head:pull/566

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


From thartmann at openjdk.java.net  Tue Oct 19 13:29:22 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 19 Oct 2021 13:29:22 GMT
Subject: [lworld] Integrated: 8274950: [lworld] LoadNode::Identity optimization
 should not skip casts
In-Reply-To: <Wbvdkg7hrrbkYpRnDDYhV5gWf_n_E7AwuYvZ3P1CaEY=.0fc81d0f-27e9-4aeb-9fc8-3ede7a02419a@github.com>
References: <Wbvdkg7hrrbkYpRnDDYhV5gWf_n_E7AwuYvZ3P1CaEY=.0fc81d0f-27e9-4aeb-9fc8-3ede7a02419a@github.com>
Message-ID: <eQSnSuh6Fju_2caCJ3LWjCYKgACo9VoKZwQkowdzHqM=.9cbd5708-715e-4098-9243-4f69e58f7036@github.com>

On Tue, 19 Oct 2021 11:26:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When implementing scalarization of nullable inline types with [JDK-8267665](https://bugs.openjdk.java.net/browse/JDK-8267665), I added code to skip cast nodes. This allows the `LoadNode::Identity` optimization to fold loads from `InlineTypePtrNodes` that are hidden behind casts. However, skipping casts is often not correct because not only do we potentially lose type information but the cast could also fail. In the reported case, we hit an assert because we are loading from an offset that does not correspond to a field in the inline type (because the cast would fail).
> 
> This patch handles cast nodes properly by pushing them up through the InlineTypePtrNode oop input.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: df020e01
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/df020e0183e5edc546af2135510b68bef364a514
Stats:     115 lines in 6 files changed: 93 ins; 1 del; 21 mod

8274950: [lworld] LoadNode::Identity optimization should not skip casts

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

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


From thartmann at openjdk.java.net  Tue Oct 19 14:28:30 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 19 Oct 2021 14:28:30 GMT
Subject: [lworld] RFR: 8272448: [lworld] C2 compilation fails with
 "Bad graph detected in build_loop_late"
Message-ID: <shwwOiymq1BzSI8_6yFMm6WEUzj0zQYTQTzuUCnLkfs=.6e69c2ec-8379-42ac-9ee9-858b31807c3f@github.com>

The assert does not reproduce anymore after merging with mainline and has most likely been resolved by one of the upstream fixes. I'm re-enabling the optimization.

Best regards,
Tobias

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

Commit messages:
 - 8272448: [lworld] C2 compilation fails with "Bad graph detected in build_loop_late"

Changes: https://git.openjdk.java.net/valhalla/pull/567/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=567&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272448
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/567.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/567/head:pull/567

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


From thartmann at openjdk.java.net  Wed Oct 20 06:06:27 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 20 Oct 2021 06:06:27 GMT
Subject: [lworld] Integrated: 8272448: [lworld] C2 compilation fails with
 "Bad graph detected in build_loop_late"
In-Reply-To: <shwwOiymq1BzSI8_6yFMm6WEUzj0zQYTQTzuUCnLkfs=.6e69c2ec-8379-42ac-9ee9-858b31807c3f@github.com>
References: <shwwOiymq1BzSI8_6yFMm6WEUzj0zQYTQTzuUCnLkfs=.6e69c2ec-8379-42ac-9ee9-858b31807c3f@github.com>
Message-ID: <qPTCxlvp8p57rbAMuIxhughZ8lLSo-s4GoQxd79UrhY=.c868a577-26b6-43bb-a02c-8deb529e44c7@github.com>

On Tue, 19 Oct 2021 14:22:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The assert does not reproduce anymore after merging with mainline and has most likely been resolved by one of the upstream fixes. I'm re-enabling the optimization.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

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

8272448: [lworld] C2 compilation fails with "Bad graph detected in build_loop_late"

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

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


From thartmann at openjdk.java.net  Wed Oct 20 10:23:36 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 20 Oct 2021 10:23:36 GMT
Subject: [lworld] RFR: 8275583: [lworld] C2 fails to scalarize inline types in
 safepoint debug info in rare cases
Message-ID: <p0jetXWiWKW0V8qArvFqWVhS1_ziLAo3lS41_CHOp9g=.c9496670-ff94-4b2f-bfe0-3d36b6a25ce4@github.com>

In rare cases, it can happen that inline types are not scalarized in safepoint debug info and we hit an assert. The problem is that `InlineTypeBaseNode::Ideal` is only called by IGVN if the node (or one of its inputs) has been modified but not if folding of output nodes leads to a direct connection to a SafePointNode. Usually, the node is still scalarized when we visit all inline type nodes via ` Compile::process_inline_types` but there are cases when that's too late and not scalarizing the node early (prevents other nodes from being removed (for example, during macro expansion).

The fix is to simply move the code to `SafePointNode::Ideal` which will be invoked whenever one of the (debug) inputs changed.

I also fixed an issue where `FastLockNodes` with an `InlineTypePtrNode` input are not folded and keep allocations alive.

Best regards,
Tobias

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

Commit messages:
 - 8275583: [lworld] C2 fails to scalarize inline types in safepoint debug info in rare cases

Changes: https://git.openjdk.java.net/valhalla/pull/568/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=568&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275583
  Stats: 48 lines in 6 files changed: 29 ins; 17 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/568.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/568/head:pull/568

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


From thartmann at openjdk.java.net  Wed Oct 20 11:29:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 20 Oct 2021 11:29:48 GMT
Subject: [lworld] RFR: 8275583: [lworld] C2 fails to scalarize inline types
 in safepoint debug info in rare cases [v2]
In-Reply-To: <p0jetXWiWKW0V8qArvFqWVhS1_ziLAo3lS41_CHOp9g=.c9496670-ff94-4b2f-bfe0-3d36b6a25ce4@github.com>
References: <p0jetXWiWKW0V8qArvFqWVhS1_ziLAo3lS41_CHOp9g=.c9496670-ff94-4b2f-bfe0-3d36b6a25ce4@github.com>
Message-ID: <S8_mkfyf5bORUGUgy4nbmYPSsYUhH0t3xr69JlLN7MY=.d3db41f1-25b8-4c43-bef6-f0bf3d8594f9@github.com>

> In rare cases, it can happen that inline types are not scalarized in safepoint debug info and we hit an assert. The problem is that `InlineTypeBaseNode::Ideal` is only called by IGVN if the node (or one of its inputs) has been modified but not if folding of output nodes leads to a direct connection to a SafePointNode. Usually, the node is still scalarized when we visit all inline type nodes via ` Compile::process_inline_types` but there are cases when that's too late and not scalarizing the node early (prevents other nodes from being removed (for example, during macro expansion).
> 
> The fix is to simply move the code to `SafePointNode::Ideal` which will be invoked whenever one of the (debug) inputs changed.
> 
> I also fixed an issue where `FastLockNodes` with an `InlineTypePtrNode` input are not folded and keep allocations alive.
> 
> Best regards,
> Tobias

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

  Unrelated fix: Use vk type when checking that casts can be pushed through

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/568/files
  - new: https://git.openjdk.java.net/valhalla/pull/568/files/d5c4acac..1514473d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=568&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=568&range=00-01

  Stats: 13 lines in 1 file changed: 9 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/568.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/568/head:pull/568

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


From thartmann at openjdk.java.net  Wed Oct 20 13:07:43 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 20 Oct 2021 13:07:43 GMT
Subject: git: openjdk/valhalla: lworld: 8275583: [lworld] C2 fails to scalarize
 inline types in safepoint debug info in rare cases
Message-ID: <31ae6222-ecdf-4dc2-9718-6ac78ee16550@openjdk.org>

Changeset: 3354fc04
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-10-20 13:07:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3354fc048ce0395c6ab512263313d8fb18583b22

8275583: [lworld] C2 fails to scalarize inline types in safepoint debug info in rare cases

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/inlinetypenode.cpp
! src/hotspot/share/opto/locknode.cpp
! src/hotspot/share/opto/locknode.hpp
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java



From thartmann at openjdk.java.net  Wed Oct 20 13:10:32 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 20 Oct 2021 13:10:32 GMT
Subject: [lworld] Integrated: 8275583: [lworld] C2 fails to scalarize inline
 types in safepoint debug info in rare cases
In-Reply-To: <p0jetXWiWKW0V8qArvFqWVhS1_ziLAo3lS41_CHOp9g=.c9496670-ff94-4b2f-bfe0-3d36b6a25ce4@github.com>
References: <p0jetXWiWKW0V8qArvFqWVhS1_ziLAo3lS41_CHOp9g=.c9496670-ff94-4b2f-bfe0-3d36b6a25ce4@github.com>
Message-ID: <DfpQ9Fzl1HFbymeXShstHtdwVgDCwkTnSAdCtUTdxGE=.116dd7c6-0ef1-4aba-bc12-10ae3c6b1968@github.com>

On Wed, 20 Oct 2021 10:17:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In rare cases, it can happen that inline types are not scalarized in safepoint debug info and we hit an assert. The problem is that `InlineTypeBaseNode::Ideal` is only called by IGVN if the node (or one of its inputs) has been modified but not if folding of output nodes leads to a direct connection to a SafePointNode. Usually, the node is still scalarized when we visit all inline type nodes via ` Compile::process_inline_types` but there are cases when that's too late and not scalarizing the node early (prevents other nodes from being removed (for example, during macro expansion).
> 
> The fix is to simply move the code to `SafePointNode::Ideal` which will be invoked whenever one of the (debug) inputs changed.
> 
> I also fixed an issue where `FastLockNodes` with an `InlineTypePtrNode` input are not folded and keep allocations alive.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 3354fc04
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3354fc048ce0395c6ab512263313d8fb18583b22
Stats:     61 lines in 7 files changed: 38 ins; 20 del; 3 mod

8275583: [lworld] C2 fails to scalarize inline types in safepoint debug info in rare cases

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

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


From thartmann at openjdk.java.net  Mon Oct 25 10:41:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 25 Oct 2021 10:41:39 GMT
Subject: [lworld] RFR: 8275797: [lworld] Scalar replacement fails with
 ShouldNotReachHere() due to unexpected load type
Message-ID: <W3iqn6VH51oUpTVFi3sNuv_XlNL71H7awMoNul6oKuA=.78145deb-1734-41e3-aede-f1ec11cf2f44@github.com>

When folding a field load from a scalar replaced, flat inline type array through an array copy, `T_ARRAY` is used instead of `T_OBJECT`. The fix is to simply convert the basic type of the field via `type2field` like we do in `InlineTypeBaseNode::load` and at other places.

Thanks,
Tobias

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

Commit messages:
 - 8275797: [lworld] Scalar replacement fails with ShouldNotReachHere() due to unexpected load type

Changes: https://git.openjdk.java.net/valhalla/pull/569/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=569&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275797
  Stats: 19 lines in 2 files changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/569.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/569/head:pull/569

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


From thartmann at openjdk.java.net  Mon Oct 25 11:24:17 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 25 Oct 2021 11:24:17 GMT
Subject: [lworld] Integrated: 8275797: [lworld] Scalar replacement fails with
 ShouldNotReachHere() due to unexpected load type
In-Reply-To: <W3iqn6VH51oUpTVFi3sNuv_XlNL71H7awMoNul6oKuA=.78145deb-1734-41e3-aede-f1ec11cf2f44@github.com>
References: <W3iqn6VH51oUpTVFi3sNuv_XlNL71H7awMoNul6oKuA=.78145deb-1734-41e3-aede-f1ec11cf2f44@github.com>
Message-ID: <R1j1gKEuFApSmJzlq0P8o8BRshH2Eq82_oj6jJ4Ulwc=.868ba08e-3c37-443b-9d60-b3278e052b9d@github.com>

On Mon, 25 Oct 2021 10:36:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When folding a field load from a scalar replaced, flat inline type array through an array copy, `T_ARRAY` is used instead of `T_OBJECT`. The fix is to simply convert the basic type of the field via `type2field` like we do in `InlineTypeBaseNode::load` and at other places.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 600ecaf5
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/600ecaf588aa67df241d07c88964b417c0a6a772
Stats:     19 lines in 2 files changed: 18 ins; 0 del; 1 mod

8275797: [lworld] Scalar replacement fails with ShouldNotReachHere() due to unexpected load type

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

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


From thartmann at openjdk.java.net  Mon Oct 25 12:35:29 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 25 Oct 2021 12:35:29 GMT
Subject: [lworld] RFR: 8275824: [lworld] C2 generates unused code (klass ptr
 check) when oop value of scalarized return is not used
Message-ID: <2yZxsPWi1hJ84MyHby4108ZhkRHCWzDFYq83rI1HlgM=.5871eaa7-62eb-4770-b18c-ff60c64e8c50@github.com>

When an inline type is returned as fields in registers, one register (`rax` on x86) either contains an oop if the inline type is buffered or a pointer to the corresponding `InlineKlass` with the lowest bit set to 1 (used by the interpreter and C1 to buffer). To use the oop, C2 emits code to zero that register if the lowest bit is set after a call. However, that code should not be emitted if the oop is never used.

Thanks to @kuksenko for reporting!

Best regards,
Tobias

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

Commit messages:
 - 8275824: [lworld] C2 generates unused code (klass ptr check) when oop value of scalarized return is not used

Changes: https://git.openjdk.java.net/valhalla/pull/570/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=570&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275824
  Stats: 7 lines in 4 files changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/570.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/570/head:pull/570

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


From thartmann at openjdk.java.net  Tue Oct 26 06:09:26 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 26 Oct 2021 06:09:26 GMT
Subject: [lworld] Integrated: 8275824: [lworld] C2 generates unused code (klass
 ptr check) when oop value of scalarized return is not used
In-Reply-To: <2yZxsPWi1hJ84MyHby4108ZhkRHCWzDFYq83rI1HlgM=.5871eaa7-62eb-4770-b18c-ff60c64e8c50@github.com>
References: <2yZxsPWi1hJ84MyHby4108ZhkRHCWzDFYq83rI1HlgM=.5871eaa7-62eb-4770-b18c-ff60c64e8c50@github.com>
Message-ID: <5q6IcP_PfOrELJDA0_ZVacwGwK8XzJgHJjRuMNNikUs=.9d260822-0198-4679-8410-9947fd70a3eb@github.com>

On Mon, 25 Oct 2021 12:30:13 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When an inline type is returned as fields in registers, one register (`rax` on x86) either contains an oop if the inline type is buffered or a pointer to the corresponding `InlineKlass` with the lowest bit set to 1 (used by the interpreter and C1 to buffer). To use the oop, C2 emits code to zero that register if the lowest bit is set after a call. However, that code should not be emitted if the oop is never used.
> 
> Thanks to @kuksenko for reporting!
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: e7ddeb2f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e7ddeb2f540750908f0712d297fe079429600df9
Stats:     7 lines in 4 files changed: 0 ins; 4 del; 3 mod

8275824: [lworld] C2 generates unused code (klass ptr check) when oop value of scalarized return is not used

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

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


From thartmann at openjdk.java.net  Tue Oct 26 11:46:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 26 Oct 2021 11:46:51 GMT
Subject: [lworld] RFR: 8275825: [lworld] Unnecessary buffering because trivial
 accessor methods are not C2 compiled
Message-ID: <U_Mo5mQZ5lfzQkY5bYjK9B41eiyP3YrTExTrFFE3aBc=.58d0f8a7-642f-48e7-822c-2dd36225ba45@github.com>

Trivial accessor (getter/setter) methods are not C2 compiled but remain at C1 level. This is problematic for methods operating on inline type fields because C1 will not perform scalarization in arguments and returns, leading to frequent buffering. The fix is to not treat these methods as trivial.

The fix also includes some refactoring and a fix to `AdapterFingerPrint::as_basic_args_string` where we hit a `ShouldNotReachHere` when printing basic types of scalarized inline type argument fields because they are not widened.

Thanks to @kuksenko for reporting!

Best regards,
Tobias

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

Commit messages:
 - Test fix
 - 8275825: [lworld] Unnecessary buffering because trivial accessor methods are not C2 compiled

Changes: https://git.openjdk.java.net/valhalla/pull/571/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=571&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275825
  Stats: 141 lines in 6 files changed: 114 ins; 11 del; 16 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/571.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/571/head:pull/571

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


From thartmann at openjdk.java.net  Tue Oct 26 12:52:37 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 26 Oct 2021 12:52:37 GMT
Subject: [lworld] Integrated: 8275825: [lworld] Unnecessary buffering because
 trivial accessor methods are not C2 compiled
In-Reply-To: <U_Mo5mQZ5lfzQkY5bYjK9B41eiyP3YrTExTrFFE3aBc=.58d0f8a7-642f-48e7-822c-2dd36225ba45@github.com>
References: <U_Mo5mQZ5lfzQkY5bYjK9B41eiyP3YrTExTrFFE3aBc=.58d0f8a7-642f-48e7-822c-2dd36225ba45@github.com>
Message-ID: <sxuQ4aYis7Cy-brthHWVLscr_227nlhlTGD3wrWYpz8=.8bbfaa28-46e9-42eb-b6f1-8c1d9cc8b369@github.com>

On Tue, 26 Oct 2021 11:31:44 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial accessor (getter/setter) methods are not C2 compiled but remain at C1 level. This is problematic for methods operating on inline type fields because C1 will not perform scalarization in arguments and returns, leading to frequent buffering. The fix is to not treat these methods as trivial.
> 
> The fix also includes some refactoring and a fix to `AdapterFingerPrint::as_basic_args_string` where we hit a `ShouldNotReachHere` when printing basic types of scalarized inline type argument fields because they are not widened.
> 
> Thanks to @kuksenko for reporting!
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 9c886f31
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9c886f310d94a66c3bc481a6484ecee4b8274e65
Stats:     141 lines in 6 files changed: 114 ins; 11 del; 16 mod

8275825: [lworld] Unnecessary buffering because trivial accessor methods are not C2 compiled

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

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


From vromero at openjdk.java.net  Tue Oct 26 17:46:47 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 26 Oct 2021 17:46:47 GMT
Subject: Integrated: updating tests
Message-ID: <jBWmSRVtoYXqh0NRnWrtbcGLgQtb2iH02MHLNHjCK5o=.8fa4e687-fc4a-40b5-93ae-3ded77c90358@github.com>

minor change to tests

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

Commit messages:
 - updating tests

Changes: https://git.openjdk.java.net/valhalla/pull/572/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=572&range=00
  Stats: 8 lines in 1 file changed: 5 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/572.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/572/head:pull/572

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


From vromero at openjdk.java.net  Tue Oct 26 17:46:48 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 26 Oct 2021 17:46:48 GMT
Subject: Integrated: updating tests
In-Reply-To: <jBWmSRVtoYXqh0NRnWrtbcGLgQtb2iH02MHLNHjCK5o=.8fa4e687-fc4a-40b5-93ae-3ded77c90358@github.com>
References: <jBWmSRVtoYXqh0NRnWrtbcGLgQtb2iH02MHLNHjCK5o=.8fa4e687-fc4a-40b5-93ae-3ded77c90358@github.com>
Message-ID: <mUVMoUDtFIHr-SRyPKPo3oogSMMo235zXthPCV3NLV4=.103110f0-ddc6-461d-a90e-a6c27dc000d0@github.com>

On Tue, 26 Oct 2021 17:41:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> minor change to tests

This pull request has now been integrated.

Changeset: 65e3943a
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/65e3943aaa39c1419469b36955c38c06ee5b16f8
Stats:     8 lines in 1 file changed: 5 ins; 2 del; 1 mod

updating tests

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

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


From dsimms at openjdk.java.net  Wed Oct 27 10:17:37 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 27 Oct 2021 10:17:37 GMT
Subject: [lworld] RFR: 8276051: [lworld] Indeterministic GC behavior in
 runtime/valhalla/inlinetypes/InlineOops.java
Message-ID: <2yOLm2fEea4AB04k-z39h_xulSWoaAMPz9CocuTNN20=.7f7f8929-c159-45f6-b6e5-a1dbb996c574@github.com>

Removed:
* unbound short lived work create
* multiple threaded short lived work
* relying Reference processing

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

Commit messages:
 - 8276051: [lworld] Indeterministic GC behavior in runtime/valhalla/inlinetypes/InlineOops.java

Changes: https://git.openjdk.java.net/valhalla/pull/573/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=573&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276051
  Stats: 60 lines in 1 file changed: 6 ins; 32 del; 22 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/573.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/573/head:pull/573

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


From dsimms at openjdk.java.net  Wed Oct 27 12:25:25 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 27 Oct 2021 12:25:25 GMT
Subject: [lworld] Integrated: 8276051: [lworld] Indeterministic GC behavior in
 runtime/valhalla/inlinetypes/InlineOops.java
In-Reply-To: <2yOLm2fEea4AB04k-z39h_xulSWoaAMPz9CocuTNN20=.7f7f8929-c159-45f6-b6e5-a1dbb996c574@github.com>
References: <2yOLm2fEea4AB04k-z39h_xulSWoaAMPz9CocuTNN20=.7f7f8929-c159-45f6-b6e5-a1dbb996c574@github.com>
Message-ID: <xyoox_xRoi2V4bi86q2P7VfllrDmK13LOPyjn56exuI=.55368d05-7cc5-4c57-a853-30eb927aecff@github.com>

On Wed, 27 Oct 2021 10:12:08 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed:
> * unbound short lived work create
> * multiple threaded short lived work
> * relying Reference processing

This pull request has now been integrated.

Changeset: f2a163cc
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f2a163cce04af3a3763aacaf8a79af877f77240e
Stats:     60 lines in 1 file changed: 6 ins; 32 del; 22 mod

8276051: [lworld] Indeterministic GC behavior in runtime/valhalla/inlinetypes/InlineOops.java

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

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


From fparain at openjdk.java.net  Wed Oct 27 16:42:51 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 27 Oct 2021 16:42:51 GMT
Subject: [lworld] RFR: 8275606: [lworld] ClassInitializationFailuresTest
 triggers assert with -XX:-UseTLAB
Message-ID: <lUlSSf_bMhsCMlLofsi6cPsX6D4bcBgpDFfHblLtjQ4=.10aced71-4e27-46a6-af17-ffa2d8906421@github.com>

Please review those small changes fixing the handling of values with a class that failed to initialized properly.
Changes in the test file are only code formatting.
Tested with Mach5, tiers 1 to 3.

Thank you,

Fred

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

Commit messages:
 - Fix handling of values with failed class initialization

Changes: https://git.openjdk.java.net/valhalla/pull/574/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=574&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275606
  Stats: 41 lines in 3 files changed: 4 ins; 1 del; 36 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/574.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/574/head:pull/574

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


From vromero at openjdk.java.net  Wed Oct 27 19:48:38 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 27 Oct 2021 19:48:38 GMT
Subject: Integrated: Primitive value conversion
Message-ID: <GltjhfaZ-qwQ-QIfatuFhCrPugB2SQcwYsivVIfwyJw=.9b8e53c5-0b45-4271-b828-794b437b9e27@github.com>

Warn on primitive value conversion

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

Commit messages:
 - primitive value conversion

Changes: https://git.openjdk.java.net/valhalla/pull/575/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=575&range=00
  Stats: 31 lines in 4 files changed: 28 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/575.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/575/head:pull/575

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


From vromero at openjdk.java.net  Wed Oct 27 19:48:40 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 27 Oct 2021 19:48:40 GMT
Subject: Integrated: Primitive value conversion
In-Reply-To: <GltjhfaZ-qwQ-QIfatuFhCrPugB2SQcwYsivVIfwyJw=.9b8e53c5-0b45-4271-b828-794b437b9e27@github.com>
References: <GltjhfaZ-qwQ-QIfatuFhCrPugB2SQcwYsivVIfwyJw=.9b8e53c5-0b45-4271-b828-794b437b9e27@github.com>
Message-ID: <7G1F7yyys53ToeVl0VXcOrGt5vVLr4deuWmgyg7PDqg=.c848bcae-1dec-44d8-a32d-8f78fae674ee@github.com>

On Wed, 27 Oct 2021 19:41:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Warn on primitive value conversion

This pull request has now been integrated.

Changeset: bc2580e1
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bc2580e107d8c98ee4ab7cb6e09eefb4064e8344
Stats:     31 lines in 4 files changed: 28 ins; 0 del; 3 mod

Primitive value conversion

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

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


From dsimms at openjdk.java.net  Thu Oct 28 08:29:24 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 28 Oct 2021 08:29:24 GMT
Subject: [lworld] RFR: 8275606: [lworld] ClassInitializationFailuresTest
 triggers assert with -XX:-UseTLAB
In-Reply-To: <lUlSSf_bMhsCMlLofsi6cPsX6D4bcBgpDFfHblLtjQ4=.10aced71-4e27-46a6-af17-ffa2d8906421@github.com>
References: <lUlSSf_bMhsCMlLofsi6cPsX6D4bcBgpDFfHblLtjQ4=.10aced71-4e27-46a6-af17-ffa2d8906421@github.com>
Message-ID: <DSBJrObNlBRMozs7zeTgGAImWcM2mwgmX1MKPQHEqtY=.7daa02f2-a61f-4b1b-b9fc-6f0215fa0bb7@github.com>

On Wed, 27 Oct 2021 16:19:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those small changes fixing the handling of values with a class that failed to initialized properly.
> Changes in the test file are only code formatting.
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

So at first glance I didn't understand why removing the klass initialized check from `InlineKlass::read_inlined_field()` was okay until I realized, well that method handles an "instance", and `defaultvalue` has the required check. But the fix specifically handles static fields, which `withfield` now has the check added (where there was previously a hole).

Unless my comment above is incorrect and we have further problems (no don't think so): Looks good.

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

Marked as reviewed by dsimms (Committer).

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


From fparain at openjdk.java.net  Thu Oct 28 13:09:32 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 28 Oct 2021 13:09:32 GMT
Subject: [lworld] RFR: 8275606: [lworld] ClassInitializationFailuresTest
 triggers assert with -XX:-UseTLAB
In-Reply-To: <lUlSSf_bMhsCMlLofsi6cPsX6D4bcBgpDFfHblLtjQ4=.10aced71-4e27-46a6-af17-ffa2d8906421@github.com>
References: <lUlSSf_bMhsCMlLofsi6cPsX6D4bcBgpDFfHblLtjQ4=.10aced71-4e27-46a6-af17-ffa2d8906421@github.com>
Message-ID: <psqWDJAOMlr4Lo7tns9cfPPv_xZ1_hE5JlMD1njV9yw=.92f4c008-ef59-49a8-98b9-b45f171bc5e8@github.com>

On Wed, 27 Oct 2021 16:19:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those small changes fixing the handling of values with a class that failed to initialized properly.
> Changes in the test file are only code formatting.
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

Classes that failed their initialization is a corner case that adds a lot of complexity.
During initialization, a class should be able to create instances of itself, but once the class is in an initialization error state, no more new instance creation should be allowed (impacts new arrays and withfield). Regarding accesses to instances that escaped during the class initialization, I've tried to align the behavior with the current behavior of identity classes: if an instance has been created, it is legal to access its fields, even if the class itself failed to successfully initialize.

Thank you for the review.

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

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


From fparain at openjdk.java.net  Fri Oct 29 15:23:28 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 29 Oct 2021 15:23:28 GMT
Subject: [lworld] Integrated: 8275606: [lworld] ClassInitializationFailuresTest
 triggers assert with -XX:-UseTLAB
In-Reply-To: <lUlSSf_bMhsCMlLofsi6cPsX6D4bcBgpDFfHblLtjQ4=.10aced71-4e27-46a6-af17-ffa2d8906421@github.com>
References: <lUlSSf_bMhsCMlLofsi6cPsX6D4bcBgpDFfHblLtjQ4=.10aced71-4e27-46a6-af17-ffa2d8906421@github.com>
Message-ID: <HUDaZplCNmTWGD2K3tZ1Vk0hyMFdXePHds3Cn3JBfrQ=.96cae104-1f5c-4f49-9bef-592cd74e368e@github.com>

On Wed, 27 Oct 2021 16:19:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those small changes fixing the handling of values with a class that failed to initialized properly.
> Changes in the test file are only code formatting.
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 90c62595
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/90c62595e82f2fc10f4f9294e563f7612543c749
Stats:     41 lines in 3 files changed: 4 ins; 1 del; 36 mod

8275606: [lworld] ClassInitializationFailuresTest triggers assert with -XX:-UseTLAB

Reviewed-by: dsimms

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

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


From fparain at openjdk.java.net  Fri Oct 29 19:06:38 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 29 Oct 2021 19:06:38 GMT
Subject: [lworld] RFR: 8276187: [lworld] [lw3] Handling of pre-loaded fields is
 inefficient
Message-ID: <Gld3oCQJD8StnGlmqy5t5ho-FtHD-vZn_uwapktLc3U=.13df964e-89ac-43d6-a607-f4165073c3ce@github.com>

Please review those changes reducing the number of time pre-loaded fields are fetched from the system dictionary.
The changes would also help supporting field circularity in the future if needed.
Tested with Mach5, tier 1 to 3.

Thank you,

Fred

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

Commit messages:
 - Rework preloading of inline fields

Changes: https://git.openjdk.java.net/valhalla/pull/576/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=576&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276187
  Stats: 48 lines in 4 files changed: 13 ins; 21 del; 14 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/576.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/576/head:pull/576

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