From jbhateja at openjdk.org  Tue Apr  1 05:45:36 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Apr 2025 05:45:36 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v2]
In-Reply-To: <Fm1GX8stPfKrVVwn77-JM5vyhvuNdwjgfcqrhaUpcVs=.6b7cea9d-3d18-413f-af89-97932bceb2bc@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <iyWwYifcmc9-FLxaInAfuTGDa0FxTVgDmTH4onUoHbY=.e57e290b-27af-4ba8-92ba-d65812fc230f@github.com>
 <Fm1GX8stPfKrVVwn77-JM5vyhvuNdwjgfcqrhaUpcVs=.6b7cea9d-3d18-413f-af89-97932bceb2bc@github.com>
Message-ID: <hOO4awFP__HOwG1GrPTpRFERCfbPLXzkbgfq5bHLzeY=.ba34f1ad-a744-45ad-910e-1ade71ab39c5@github.com>

On Mon, 31 Mar 2025 04:24:23 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments, set and unset larval bit
>
> I filed https://bugs.openjdk.org/browse/JDK-8353236 for improving the javadoc and I will file another issue later to try our best catching the illegal uses in C2.

Hi @merykitty , 
Thanks for clearly spelling out the UNSAFE API semantics it chops out ambiguities about
context in which larval values can be used.

The approach looks correct to me and aligns with larval handling in lworld+vector.

I see you have not addressed some minor comments around comment reformatting, but we can address those along with PR 1405 :-)

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2768157448

From mcimadamore at openjdk.org  Tue Apr  1 15:09:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Apr 2025 15:09:48 GMT
Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for
 instance field initializers [v5]
In-Reply-To: <BOQMMd5peKw-9ibMZf2oJpHhVO5aNxCTvrE0Bubmyc0=.16fd517f-72f4-4810-8882-0f16289aa8c4@github.com>
References: <iXSDm9-9JPr8xjy7zQd8lyqcx6ocUaYAR0hgQHV9CHk=.afe645d0-738a-49cf-b9a5-6518eb37e05f@github.com>
 <BOQMMd5peKw-9ibMZf2oJpHhVO5aNxCTvrE0Bubmyc0=.16fd517f-72f4-4810-8882-0f16289aa8c4@github.com>
Message-ID: <TvgQHy6XLO33hMnuXmWgarBwpmEi_WAEM2N4pL0tlnE=.976f8d55-55e7-478b-a56b-19e97c2a8793@github.com>

On Mon, 31 Mar 2025 21:17:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Proxy locals are added as a new compiler phase which is executed just before code generation.
>> 
>> Q - what it does?
>> A - basically for code like:
>> 
>> abstract value class Super {
>>     Super(String s) {}
>> }
>> 
>> value class V extends Super {
>>     int i;
>>     V(String s) {
>>         if (s != null) {
>>             i = 100;
>>         } else {
>>             i = 200;
>>         }
>>         super("100" + s);
>>     }
>> }
>> 
>> javac will generate for V's constructor something in the lines of:
>> 
>>     V(String s) {
>>         /*synthetic*/ int local$i;
>>         if (s != null) {
>>             local$i = 100;
>>         } else {
>>             local$i = 200;
>>         }
>>         {
>>             /*synthetic*/ final String local$0 = "100" + s;
>>             i = local$i;
>>             super(local$0);
>>         }
>>     }
>> 
>> so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable.
>> 
>> Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor.
>> 
>> Q - does it interacts with other valhalla features?
>> A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now
>> Q- is it on by default?
>> A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests
>> 
>> TIA for any comments
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding tests

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 259:

> 257:         public void visitApply(JCTree.JCMethodInvocation tree) {
> 258:             Name methName = TreeInfo.name(tree.meth);
> 259:             boolean isConstructorCall = methName == names._this || methName == names._super;

Should this use TreeInfo::isConstructor call?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1403#discussion_r2023053992

From mcimadamore at openjdk.org  Tue Apr  1 15:15:25 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Apr 2025 15:15:25 GMT
Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for
 instance field initializers [v5]
In-Reply-To: <BOQMMd5peKw-9ibMZf2oJpHhVO5aNxCTvrE0Bubmyc0=.16fd517f-72f4-4810-8882-0f16289aa8c4@github.com>
References: <iXSDm9-9JPr8xjy7zQd8lyqcx6ocUaYAR0hgQHV9CHk=.afe645d0-738a-49cf-b9a5-6518eb37e05f@github.com>
 <BOQMMd5peKw-9ibMZf2oJpHhVO5aNxCTvrE0Bubmyc0=.16fd517f-72f4-4810-8882-0f16289aa8c4@github.com>
Message-ID: <3X4rLWNE3YmU4ojGkQtP5kUyd0V9r2DJ5afnXYoAKmE=.b9566a88-2899-43e9-922b-b26103196d9d@github.com>

On Mon, 31 Mar 2025 21:17:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Proxy locals are added as a new compiler phase which is executed just before code generation.
>> 
>> Q - what it does?
>> A - basically for code like:
>> 
>> abstract value class Super {
>>     Super(String s) {}
>> }
>> 
>> value class V extends Super {
>>     int i;
>>     V(String s) {
>>         if (s != null) {
>>             i = 100;
>>         } else {
>>             i = 200;
>>         }
>>         super("100" + s);
>>     }
>> }
>> 
>> javac will generate for V's constructor something in the lines of:
>> 
>>     V(String s) {
>>         /*synthetic*/ int local$i;
>>         if (s != null) {
>>             local$i = 100;
>>         } else {
>>             local$i = 200;
>>         }
>>         {
>>             /*synthetic*/ final String local$0 = "100" + s;
>>             i = local$i;
>>             super(local$0);
>>         }
>>     }
>> 
>> so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable.
>> 
>> Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor.
>> 
>> Q - does it interacts with other valhalla features?
>> A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now
>> Q- is it on by default?
>> A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests
>> 
>> TIA for any comments
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding tests

Marked as reviewed by mcimadamore (Committer).

Overall, this should be good enough to be integrated

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

PR Review: https://git.openjdk.org/valhalla/pull/1403#pullrequestreview-2733055789
PR Comment: https://git.openjdk.org/valhalla/pull/1403#issuecomment-2769705753

From mcimadamore at openjdk.org  Tue Apr  1 15:15:26 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Apr 2025 15:15:26 GMT
Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for
 instance field initializers [v3]
In-Reply-To: <oQQjzzF8G-hsE0LWDUHhB7XDHGx7sOTAQBhT2PZMYAM=.bf2dd9d3-de17-4bec-9d3e-8f4f986ea621@github.com>
References: <iXSDm9-9JPr8xjy7zQd8lyqcx6ocUaYAR0hgQHV9CHk=.afe645d0-738a-49cf-b9a5-6518eb37e05f@github.com>
 <jbdwnL-j61xIm-WVsvcsYkwpD9pDYaxzCp_p4IK9WiM=.0b4f2898-6042-47cd-a4e4-7d126ccd53a8@github.com>
 <FPZRURwBLMchmDCY2yMjjJPKf9UgO-u3yklyzEfPW0A=.d3198236-2edd-489f-810e-acd5980a33b9@github.com>
 <oQQjzzF8G-hsE0LWDUHhB7XDHGx7sOTAQBhT2PZMYAM=.bf2dd9d3-de17-4bec-9d3e-8f4f986ea621@github.com>
Message-ID: <edxSQZ9ZfTyJfgNvCWq4n-c4fiinbJ8VDMMt7pGa9Os=.ac46cc2a-a601-488e-9d9a-2cc4877a7353@github.com>

On Mon, 31 Mar 2025 17:05:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > It seems like there's few more cleanup opportunities now that we detect "early" strict field instance reads in `Resolve` (which make things a lot simpler).
> > Note: a possible different implementation tactic could be to add some info to JCIdent/JCFieldAccess, so that we can record that the accessed field was instance strict, and that access was "early" (or, we could create a special variable symbol to communicate this). This would eliminate the need for a map. And would also be a bit more precise when rewriting -- because we can only rewrite field accesses that have the special tree/symbol -- and leave the other in place.
> 
> not sure what would be the benefit of rewriting some accesses and some not, also there could be two sources of truth for a given field

Yeah - it makes the rewrital easier (because you can tell what to rewrite more easily), but you still need to know the list of symbols to proxy upfront

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

PR Comment: https://git.openjdk.org/valhalla/pull/1403#issuecomment-2769704106

From vromero at openjdk.org  Tue Apr  1 17:33:21 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 1 Apr 2025 17:33:21 GMT
Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for
 instance field initializers [v5]
In-Reply-To: <BOQMMd5peKw-9ibMZf2oJpHhVO5aNxCTvrE0Bubmyc0=.16fd517f-72f4-4810-8882-0f16289aa8c4@github.com>
References: <iXSDm9-9JPr8xjy7zQd8lyqcx6ocUaYAR0hgQHV9CHk=.afe645d0-738a-49cf-b9a5-6518eb37e05f@github.com>
 <BOQMMd5peKw-9ibMZf2oJpHhVO5aNxCTvrE0Bubmyc0=.16fd517f-72f4-4810-8882-0f16289aa8c4@github.com>
Message-ID: <DE5v8j5fg-1o7Q3foetc0RWBTAAWcrAqJoze42dGRzE=.fd2bf53e-d9ca-46c1-b720-ba07f1f76ac2@github.com>

On Mon, 31 Mar 2025 21:17:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Proxy locals are added as a new compiler phase which is executed just before code generation.
>> 
>> Q - what it does?
>> A - basically for code like:
>> 
>> abstract value class Super {
>>     Super(String s) {}
>> }
>> 
>> value class V extends Super {
>>     int i;
>>     V(String s) {
>>         if (s != null) {
>>             i = 100;
>>         } else {
>>             i = 200;
>>         }
>>         super("100" + s);
>>     }
>> }
>> 
>> javac will generate for V's constructor something in the lines of:
>> 
>>     V(String s) {
>>         /*synthetic*/ int local$i;
>>         if (s != null) {
>>             local$i = 100;
>>         } else {
>>             local$i = 200;
>>         }
>>         {
>>             /*synthetic*/ final String local$0 = "100" + s;
>>             i = local$i;
>>             super(local$0);
>>         }
>>     }
>> 
>> so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable.
>> 
>> Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor.
>> 
>> Q - does it interacts with other valhalla features?
>> A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now
>> Q- is it on by default?
>> A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests
>> 
>> TIA for any comments
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding tests

thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1403#issuecomment-2770190910

From vromero at openjdk.org  Tue Apr  1 17:33:22 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 1 Apr 2025 17:33:22 GMT
Subject: [lworld] Integrated: 8334484: [lworld] new translation strategy for
 instance field initializers
In-Reply-To: <iXSDm9-9JPr8xjy7zQd8lyqcx6ocUaYAR0hgQHV9CHk=.afe645d0-738a-49cf-b9a5-6518eb37e05f@github.com>
References: <iXSDm9-9JPr8xjy7zQd8lyqcx6ocUaYAR0hgQHV9CHk=.afe645d0-738a-49cf-b9a5-6518eb37e05f@github.com>
Message-ID: <Na9ujBNFefqnjLHUirMx1iYM1VqkPPIhRoDW-DXp1wk=.10364f87-b343-4efe-bd7c-5539c937f2aa@github.com>

On Wed, 19 Mar 2025 19:26:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Proxy locals are added as a new compiler phase which is executed just before code generation.
> 
> Q - what it does?
> A - basically for code like:
> 
> abstract value class Super {
>     Super(String s) {}
> }
> 
> value class V extends Super {
>     int i;
>     V(String s) {
>         if (s != null) {
>             i = 100;
>         } else {
>             i = 200;
>         }
>         super("100" + s);
>     }
> }
> 
> javac will generate for V's constructor something in the lines of:
> 
>     V(String s) {
>         /*synthetic*/ int local$i;
>         if (s != null) {
>             local$i = 100;
>         } else {
>             local$i = 200;
>         }
>         {
>             /*synthetic*/ final String local$0 = "100" + s;
>             i = local$i;
>             super(local$0);
>         }
>     }
> 
> so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable.
> 
> Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor.
> 
> Q - does it interacts with other valhalla features?
> A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now
> Q- is it on by default?
> A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests
> 
> TIA for any comments

This pull request has now been integrated.

Changeset: 66ee27af
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/66ee27af3118e268061bd5078dd9bd09623b68ee
Stats:     397 lines in 12 files changed: 371 ins; 3 del; 23 mod

8334484: [lworld] new translation strategy for instance field initializers

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/valhalla/pull/1403

From qamai at openjdk.org  Tue Apr  1 17:50:00 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 1 Apr 2025 17:50:00 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v3]
In-Reply-To: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
Message-ID: <BBR9uYfyiOdAoEDDgXtqzAFCRMEImi99sr0gkYviuNU=.1f06d61f-a614-448e-aeba-4f3149a8bb01@github.com>

> Hi,
> 
> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
> 
> Please take a look and review this PR, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1406/files
  - new: https://git.openjdk.org/valhalla/pull/1406/files/70c7030c..3c3082ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=01-02

  Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1406.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1406/head:pull/1406

PR: https://git.openjdk.org/valhalla/pull/1406

From qamai at openjdk.org  Tue Apr  1 17:50:01 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 1 Apr 2025 17:50:01 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v2]
In-Reply-To: <iyWwYifcmc9-FLxaInAfuTGDa0FxTVgDmTH4onUoHbY=.e57e290b-27af-4ba8-92ba-d65812fc230f@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <iyWwYifcmc9-FLxaInAfuTGDa0FxTVgDmTH4onUoHbY=.e57e290b-27af-4ba8-92ba-d65812fc230f@github.com>
Message-ID: <djy5lYravCEmIspnfIPDyt5W3QIDEmCm-tCc1TPb37c=.49e2cd92-f648-45ec-a94a-25a0b55b809a@github.com>

On Wed, 26 Mar 2025 14:14:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
>> 
>> Please take a look and review this PR, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments, set and unset larval bit

I have added a test that uses `Unsafe` in a proper way and crashes.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2770229263

From qamai at openjdk.org  Tue Apr  1 17:50:03 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 1 Apr 2025 17:50:03 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v2]
In-Reply-To: <HtUkebfw0Gv6NKwdVIAfUaAy4QL74jks4Be-0aIlYLs=.88583dac-fbf8-4943-8594-6299e9ed61aa@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <iyWwYifcmc9-FLxaInAfuTGDa0FxTVgDmTH4onUoHbY=.e57e290b-27af-4ba8-92ba-d65812fc230f@github.com>
 <HtUkebfw0Gv6NKwdVIAfUaAy4QL74jks4Be-0aIlYLs=.88583dac-fbf8-4943-8594-6299e9ed61aa@github.com>
Message-ID: <YKS2OPfJ5vfuD5kdzzA7s4T4icixpprsTF8GsQK4Nc8=.c45a0fbf-57c6-487b-baf0-c5f5b79e55dd@github.com>

On Sun, 30 Mar 2025 13:03:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments, set and unset larval bit
>
> src/hotspot/share/opto/library_call.cpp line 2669:
> 
>> 2667:   const Type* type = gvn().type(value);
>> 2668:   if (!type->is_inlinetypeptr()) {
>> 2669:     C->record_method_not_compilable("value passed to Unsafe::makePrivateBuffer is not of a constant value type");
> 
> Suggestion:
> 
>     C->record_method_not_compilable("Argument passed to Unsafe::makePrivateBuffer is not a concrete value type");

I believe we do often not capitalize the first letter passed into `C->record_method_not_compilable`. Additionally, what is passed into `Unsafe::makePrivateBuffer` is a value object, not a concrete value type, and we cannot compile this method because we cannot statically determine the value type this object belongs to, not because the object is not actually a value object. If it is not a value object we will just crash here instead.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2023390468

From jbhateja at openjdk.org  Wed Apr  2 01:20:18 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Apr 2025 01:20:18 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v2]
In-Reply-To: <YKS2OPfJ5vfuD5kdzzA7s4T4icixpprsTF8GsQK4Nc8=.c45a0fbf-57c6-487b-baf0-c5f5b79e55dd@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <iyWwYifcmc9-FLxaInAfuTGDa0FxTVgDmTH4onUoHbY=.e57e290b-27af-4ba8-92ba-d65812fc230f@github.com>
 <HtUkebfw0Gv6NKwdVIAfUaAy4QL74jks4Be-0aIlYLs=.88583dac-fbf8-4943-8594-6299e9ed61aa@github.com>
 <YKS2OPfJ5vfuD5kdzzA7s4T4icixpprsTF8GsQK4Nc8=.c45a0fbf-57c6-487b-baf0-c5f5b79e55dd@github.com>
Message-ID: <GA6Id09RuuvgzoXlBR60rT5ftGuvfk9quGUaAm3DnV0=.8e871299-5ae6-4460-ab90-ec97f8bcbfa8@github.com>

On Tue, 1 Apr 2025 17:46:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 2669:
>> 
>>> 2667:   const Type* type = gvn().type(value);
>>> 2668:   if (!type->is_inlinetypeptr()) {
>>> 2669:     C->record_method_not_compilable("value passed to Unsafe::makePrivateBuffer is not of a constant value type");
>> 
>> Suggestion:
>> 
>>     C->record_method_not_compilable("Argument passed to Unsafe::makePrivateBuffer is not a concrete value type");
>
> I believe we do often not capitalize the first letter passed into `C->record_method_not_compilable`. Additionally, what is passed into `Unsafe::makePrivateBuffer` is a value object, not a concrete value type, and we cannot compile this method because we cannot statically determine the value type this object belongs to, not because the object is not actually a value object. If it is not a value object we will just crash here instead.

A reference of identity class, or an abstract value class does not carry an InlineType. Only a concrete value type is valid argument for makePrivateBuffer.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2023870134

From jbhateja at openjdk.org  Wed Apr  2 01:30:22 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Apr 2025 01:30:22 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v3]
In-Reply-To: <BBR9uYfyiOdAoEDDgXtqzAFCRMEImi99sr0gkYviuNU=.1f06d61f-a614-448e-aeba-4f3149a8bb01@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <BBR9uYfyiOdAoEDDgXtqzAFCRMEImi99sr0gkYviuNU=.1f06d61f-a614-448e-aeba-4f3149a8bb01@github.com>
Message-ID: <RWBut-eHHJw2IlYZL5yoH8WwaiGbnr8I5hJmS24hYVk=.03534383-d93c-438d-881a-b484e205417a@github.com>

On Tue, 1 Apr 2025 17:50:00 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
>> 
>> Please take a look and review this PR, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

Hi @merykitty ,
Patch looks good to me.

Thanks for clarifications and clearly spelling out UNSAFE semantics in  https://bugs.openjdk.org/browse/JDK-8353236

Best Regards,
Jatin

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 1694:

> 1692:             U.putInt(v, X_OFFSET, i);
> 1693:         }
> 1694:         U.putInt(v, X_OFFSET, rI);

Here, crash occurs becausethe compiler expects to receive an InlineTypeNode for  value type objects, since we are now buffering this value in make private buffer hence we hit following assertion failure

https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/parse1.cpp#L1789

FTR, this test does not capture a scenario where we merge a larval and non-larval value as depicted by the following case, but can hit the assertion failure.
https://github.com/user-attachments/files/19501609/unsafe_access.txt

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

Marked as reviewed by jbhateja (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1406#pullrequestreview-2734344080
PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2023874442

From qamai at openjdk.org  Wed Apr  2 06:27:30 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 2 Apr 2025 06:27:30 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v2]
In-Reply-To: <hOO4awFP__HOwG1GrPTpRFERCfbPLXzkbgfq5bHLzeY=.ba34f1ad-a744-45ad-910e-1ade71ab39c5@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <iyWwYifcmc9-FLxaInAfuTGDa0FxTVgDmTH4onUoHbY=.e57e290b-27af-4ba8-92ba-d65812fc230f@github.com>
 <Fm1GX8stPfKrVVwn77-JM5vyhvuNdwjgfcqrhaUpcVs=.6b7cea9d-3d18-413f-af89-97932bceb2bc@github.com>
 <hOO4awFP__HOwG1GrPTpRFERCfbPLXzkbgfq5bHLzeY=.ba34f1ad-a744-45ad-910e-1ade71ab39c5@github.com>
Message-ID: <mXMTQYny605rpmhfr5yJcFTC4fTbEMaBZPmQWtre23E=.1acc9454-3063-40f2-8fc2-174be2394173@github.com>

On Tue, 1 Apr 2025 05:42:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I filed https://bugs.openjdk.org/browse/JDK-8353236 for improving the javadoc and I will file another issue later to try our best catching the illegal uses in C2.
>
> Hi @merykitty , 
> Thanks for clearly spelling out the UNSAFE API semantics it chops out ambiguities about
> context in which larval values can be used.
> 
> The approach looks correct to me and aligns with larval handling in lworld+vector.
> 
> I see you have not addressed some minor comments around comments reformatting, 
> Should we include the crash test in this PR  and add it to ProblemList.txt for now?
> 
> https://github.com/user-attachments/files/19501609/unsafe_access.txt
> 
> Best Regards,
> Jatin

Thank @jatin-bhateja for the reviews and profound discussion.

@TobiHartmann Do I need to wait for you to run some tests?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2771454201

From thartmann at openjdk.org  Wed Apr  2 13:31:13 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Apr 2025 13:31:13 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v2]
In-Reply-To: <mXMTQYny605rpmhfr5yJcFTC4fTbEMaBZPmQWtre23E=.1acc9454-3063-40f2-8fc2-174be2394173@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <iyWwYifcmc9-FLxaInAfuTGDa0FxTVgDmTH4onUoHbY=.e57e290b-27af-4ba8-92ba-d65812fc230f@github.com>
 <Fm1GX8stPfKrVVwn77-JM5vyhvuNdwjgfcqrhaUpcVs=.6b7cea9d-3d18-413f-af89-97932bceb2bc@github.com>
 <hOO4awFP__HOwG1GrPTpRFERCfbPLXzkbgfq5bHLzeY=.ba34f1ad-a744-45ad-910e-1ade71ab39c5@github.com>
 <mXMTQYny605rpmhfr5yJcFTC4fTbEMaBZPmQWtre23E=.1acc9454-3063-40f2-8fc2-174be2394173@github.com>
Message-ID: <DTqn6XKZ91WXDkOnjcMAB1Bn48BevQ4TsqaL85bfpZo=.e35531d2-46a0-4d52-bb48-31b5cab15869@github.com>

On Wed, 2 Apr 2025 06:24:27 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi @merykitty , 
>> Thanks for clearly spelling out the UNSAFE API semantics it chops out ambiguities about
>> context in which larval values can be used.
>> 
>> The approach looks correct to me and aligns with larval handling in lworld+vector.
>> 
>> I see you have not addressed some minor comments around comments reformatting, 
>> Should we include the crash test in this PR  and add it to ProblemList.txt for now?
>> 
>> https://github.com/user-attachments/files/19501609/unsafe_access.txt
>> 
>> Best Regards,
>> Jatin
>
> Thank @jatin-bhateja for the reviews and profound discussion.
> 
> @TobiHartmann Do I need to wait for you to run some tests?

Thanks for asking, @merykitty. I'll run some testing and will report back.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2772570054

From thartmann at openjdk.org  Thu Apr  3 12:11:07 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 3 Apr 2025 12:11:07 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v3]
In-Reply-To: <BBR9uYfyiOdAoEDDgXtqzAFCRMEImi99sr0gkYviuNU=.1f06d61f-a614-448e-aeba-4f3149a8bb01@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <BBR9uYfyiOdAoEDDgXtqzAFCRMEImi99sr0gkYviuNU=.1f06d61f-a614-448e-aeba-4f3149a8bb01@github.com>
Message-ID: <9Q4fRM5meif_wlfw4LQht1j9OHRENN70sp5BUv_L2a0=.649c8168-b7ad-44dc-acb3-13a0d48233bc@github.com>

On Tue, 1 Apr 2025 17:50:00 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
>> 
>> Please take a look and review this PR, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

`compiler/valhalla/inlinetypes/TestIntrinsics.java` fails with `-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressArrayCopyMacroNode -XX:+StressCallingConvention -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP -XX:+StressIGVN -XX:+StressReflectiveCode -XX:+StressMethodHandleLinkerInlining -XX:+StressCompiledExceptionHandlers -XX:MaxNodeLimit=100000` in all scenarios due to:

Custom Run Test: @Run: test22_verifier - @Test: test22:
compiler.lib.ir_framework.shared.TestRunException: Method public void compiler.valhalla.inlinetypes.TestIntrinsics.test22(compiler.valhalla.inlinetypes.MyValue1) not compilable (anymore) at level C2
	at compiler.lib.ir_framework.shared.TestRun.check(TestRun.java:32)
	at compiler.lib.ir_framework.test.AbstractTest.enqueueMethodForCompilation(AbstractTest.java:156)
	at compiler.lib.ir_framework.test.AbstractTest.compileMethod(AbstractTest.java:131)
	at compiler.lib.ir_framework.test.CustomRunTest.compileSingleTest(CustomRunTest.java:113)
	at compiler.lib.ir_framework.test.CustomRunTest.compileTest(CustomRunTest.java:101)
	at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:101)
	at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89)
	at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:867)
	at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:255)
	at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:168)


Custom Run Test: @Run: test39_verifier - @Test: test39:
compiler.lib.ir_framework.shared.TestRunException: Method public compiler.valhalla.inlinetypes.MyValue1 compiler.valhalla.inlinetypes.TestIntrinsics.test39(compiler.valhalla.inlinetypes.MyValue1) not compilable (anymore) at level C2
	at compiler.lib.ir_framework.shared.TestRun.check(TestRun.java:32)
	at compiler.lib.ir_framework.test.AbstractTest.enqueueMethodForCompilation(AbstractTest.java:156)
	at compiler.lib.ir_framework.test.AbstractTest.compileMethod(AbstractTest.java:131)
	at compiler.lib.ir_framework.test.CustomRunTest.compileSingleTest(CustomRunTest.java:113)
	at compiler.lib.ir_framework.test.CustomRunTest.compileTest(CustomRunTest.java:101)
	at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:101)
	at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89)
	at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:867)
	at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:255)
	at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:168)


	at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:903)
	at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:255)
	at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:168)

Otherwise, testing looks good!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2775582742
PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2775583243

From thartmann at openjdk.org  Thu Apr  3 12:29:36 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 3 Apr 2025 12:29:36 GMT
Subject: [lworld] Integrated: 8353639: [lworld] IGV: Fix broken type info
 filter with TypeAryPtr::_field_offset
In-Reply-To: <X3ljm3V2UtoeD9IJ4lj1lEoqDn_opqZnofwDjq7Orms=.d5b1fe05-fee4-4607-97f9-2c832e5ddb68@github.com>
References: <X3ljm3V2UtoeD9IJ4lj1lEoqDn_opqZnofwDjq7Orms=.d5b1fe05-fee4-4607-97f9-2c832e5ddb68@github.com>
Message-ID: <4M1IhZ8DeT9qnTr5snkz4LiWWGH7mWYpH1rj6qy1kUs=.7ed08196-5575-4657-ab02-7dd2fa849222@github.com>

On Thu, 3 Apr 2025 12:19:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The `TypeAryPtr::_field_offset` information is dumped inside a pair of braces:
> 
>                                                          --> HERE <--
> flat:narrowoop: V1:NotNull:exact *[int:?0]:NotNull:exact:flat(+4):null_free[2] * [narrow]
> 
> The problem is that the type info filter from mainline only expects that interface types are found inside braces and then tries to remove them. This now messes with two pair of braces.
> 
> The fix I propose is to match anything but the first closing `)` when finding the first `(` with `([^)]*)` for the interface types instead of matching it with `(.*)` which matches up to the field offset.
> 
> Without fix:
> ![Screenshot from 2025-04-03 13-57-20](https://github.com/user-attachments/assets/3baf40df-2ea4-4b7d-a450-6dca200b986f)
> 
> With fix:
> ![Screenshot from 2025-04-03 13-59-20](https://github.com/user-attachments/assets/a5c97f9e-cd70-4f81-af85-5bd8c960f4aa)
> 
> Thanks,
> Christian

Good catch, looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1414#pullrequestreview-2739658807

From chagedorn at openjdk.org  Thu Apr  3 12:29:36 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 3 Apr 2025 12:29:36 GMT
Subject: [lworld] Integrated: 8353639: [lworld] IGV: Fix broken type info
 filter with TypeAryPtr::_field_offset
Message-ID: <X3ljm3V2UtoeD9IJ4lj1lEoqDn_opqZnofwDjq7Orms=.d5b1fe05-fee4-4607-97f9-2c832e5ddb68@github.com>

The `TypeAryPtr::_field_offset` information is dumped inside a pair of braces:

                                                         --> HERE <--
flat:narrowoop: V1:NotNull:exact *[int:?0]:NotNull:exact:flat(+4):null_free[2] * [narrow]

The problem is that the type info filter from mainline only expects that interface types are found inside braces and then tries to remove them. This now messes with two pair of braces.

The fix I propose is to match anything but the first closing `)` when finding the first `(` with `([^)]*)` for the interface types instead of matching it with `(.*)` which matches up to the field offset.

Without fix:
![Screenshot from 2025-04-03 13-57-20](https://github.com/user-attachments/assets/3baf40df-2ea4-4b7d-a450-6dca200b986f)

With fix:
![Screenshot from 2025-04-03 13-59-20](https://github.com/user-attachments/assets/a5c97f9e-cd70-4f81-af85-5bd8c960f4aa)

Thanks,
Christian

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

Commit messages:
 - 8353639: [lworld] IGV: Fix broken type info filter with TypeAryPtr::_field_offset

Changes: https://git.openjdk.org/valhalla/pull/1414/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1414&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353639
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1414.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1414/head:pull/1414

PR: https://git.openjdk.org/valhalla/pull/1414

From chagedorn at openjdk.org  Thu Apr  3 12:29:36 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 3 Apr 2025 12:29:36 GMT
Subject: [lworld] Integrated: 8353639: [lworld] IGV: Fix broken type info
 filter with TypeAryPtr::_field_offset
In-Reply-To: <X3ljm3V2UtoeD9IJ4lj1lEoqDn_opqZnofwDjq7Orms=.d5b1fe05-fee4-4607-97f9-2c832e5ddb68@github.com>
References: <X3ljm3V2UtoeD9IJ4lj1lEoqDn_opqZnofwDjq7Orms=.d5b1fe05-fee4-4607-97f9-2c832e5ddb68@github.com>
Message-ID: <CDIL1QEBpsETvJFI-ONXmcI-ASnu2hHxQYRd2fF_m54=.02bff343-2dca-490c-8fb6-afdbd700a534@github.com>

On Thu, 3 Apr 2025 12:19:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The `TypeAryPtr::_field_offset` information is dumped inside a pair of braces:
> 
>                                                          --> HERE <--
> flat:narrowoop: V1:NotNull:exact *[int:?0]:NotNull:exact:flat(+4):null_free[2] * [narrow]
> 
> The problem is that the type info filter from mainline only expects that interface types are found inside braces and then tries to remove them. This now messes with two pair of braces.
> 
> The fix I propose is to match anything but the first closing `)` when finding the first `(` with `([^)]*)` for the interface types instead of matching it with `(.*)` which matches up to the field offset.
> 
> Without fix:
> ![Screenshot from 2025-04-03 13-57-20](https://github.com/user-attachments/assets/3baf40df-2ea4-4b7d-a450-6dca200b986f)
> 
> With fix:
> ![Screenshot from 2025-04-03 13-59-20](https://github.com/user-attachments/assets/a5c97f9e-cd70-4f81-af85-5bd8c960f4aa)
> 
> Thanks,
> Christian

Thanks Tobias for your quick review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1414#issuecomment-2775621153

From chagedorn at openjdk.org  Thu Apr  3 12:29:37 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 3 Apr 2025 12:29:37 GMT
Subject: [lworld] Integrated: 8353639: [lworld] IGV: Fix broken type info
 filter with TypeAryPtr::_field_offset
In-Reply-To: <X3ljm3V2UtoeD9IJ4lj1lEoqDn_opqZnofwDjq7Orms=.d5b1fe05-fee4-4607-97f9-2c832e5ddb68@github.com>
References: <X3ljm3V2UtoeD9IJ4lj1lEoqDn_opqZnofwDjq7Orms=.d5b1fe05-fee4-4607-97f9-2c832e5ddb68@github.com>
Message-ID: <WeGRK7kExIq1OKDDbfk0-XF2vQjn6JZXooUa2rqhj-M=.aeefa3f9-81d9-4ece-aaa1-67006ae4c741@github.com>

On Thu, 3 Apr 2025 12:19:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The `TypeAryPtr::_field_offset` information is dumped inside a pair of braces:
> 
>                                                          --> HERE <--
> flat:narrowoop: V1:NotNull:exact *[int:?0]:NotNull:exact:flat(+4):null_free[2] * [narrow]
> 
> The problem is that the type info filter from mainline only expects that interface types are found inside braces and then tries to remove them. This now messes with two pair of braces.
> 
> The fix I propose is to match anything but the first closing `)` when finding the first `(` with `([^)]*)` for the interface types instead of matching it with `(.*)` which matches up to the field offset.
> 
> Without fix:
> ![Screenshot from 2025-04-03 13-57-20](https://github.com/user-attachments/assets/3baf40df-2ea4-4b7d-a450-6dca200b986f)
> 
> With fix:
> ![Screenshot from 2025-04-03 13-59-20](https://github.com/user-attachments/assets/a5c97f9e-cd70-4f81-af85-5bd8c960f4aa)
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: f662357d
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f662357d3a5b78aa7f89ce81a04f39185a3d233a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8353639: [lworld] IGV: Fix broken type info filter with TypeAryPtr::_field_offset

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1414

From qamai at openjdk.org  Thu Apr  3 17:02:51 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 3 Apr 2025 17:02:51 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v4]
In-Reply-To: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
Message-ID: <2gMpWbVVWznlg9PUBkBP7ttau9HalkwjgC1OhhabW3o=.719eb759-55d8-4667-a68b-41407d31cdb1@github.com>

> Hi,
> 
> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
> 
> Please take a look and review this PR, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix StressReflectiveCode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1406/files
  - new: https://git.openjdk.org/valhalla/pull/1406/files/3c3082ae..f597c9e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=02-03

  Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1406.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1406/head:pull/1406

PR: https://git.openjdk.org/valhalla/pull/1406

From qamai at openjdk.org  Thu Apr  3 17:02:53 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 3 Apr 2025 17:02:53 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v3]
In-Reply-To: <9Q4fRM5meif_wlfw4LQht1j9OHRENN70sp5BUv_L2a0=.649c8168-b7ad-44dc-acb3-13a0d48233bc@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <BBR9uYfyiOdAoEDDgXtqzAFCRMEImi99sr0gkYviuNU=.1f06d61f-a614-448e-aeba-4f3149a8bb01@github.com>
 <9Q4fRM5meif_wlfw4LQht1j9OHRENN70sp5BUv_L2a0=.649c8168-b7ad-44dc-acb3-13a0d48233bc@github.com>
Message-ID: <POAo7wHkncZaFNrHECFf1VTR4j9AljlqxDOe8mPVBc4=.8aef087e-2be1-4aa2-8bad-a4a3f5aa0ce8@github.com>

On Thu, 3 Apr 2025 12:08:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test
>
> Otherwise, testing looks good!

@TobiHartmann Thanks a lot, I have fixed the issue, you can find the explanation I have just added.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2776420025

From vromero at openjdk.org  Thu Apr  3 17:30:33 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Apr 2025 17:30:33 GMT
Subject: [lworld] Integrated: 8353664: [lworld] missing code for fix for
 JDK-8334484
In-Reply-To: <lvWsI7oqAV_UeQx_9YQaH93w0Ob-BtOyT3-2GRX-LYY=.abd06a49-9160-420c-90e5-fcbea1a48472@github.com>
References: <lvWsI7oqAV_UeQx_9YQaH93w0Ob-BtOyT3-2GRX-LYY=.abd06a49-9160-420c-90e5-fcbea1a48472@github.com>
Message-ID: <XkemKpaQhxSBJXPnLesY7p5SPfSn0VNsfRpezet_d1w=.f15464ac-5bb5-4947-bd1f-b56554e9687a@github.com>

On Thu, 3 Apr 2025 17:24:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> just minor refactoring that was not integrated with fix for JDK-8334484

This pull request has now been integrated.

Changeset: 71d05790
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/71d05790b73a978a5df67a4a8bdcab2a5e7cac1b
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8353664: [lworld] missing code for fix for JDK-8334484

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

PR: https://git.openjdk.org/valhalla/pull/1415

From vromero at openjdk.org  Thu Apr  3 17:30:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Apr 2025 17:30:32 GMT
Subject: [lworld] Integrated: 8353664: [lworld] missing code for fix for
 JDK-8334484
Message-ID: <lvWsI7oqAV_UeQx_9YQaH93w0Ob-BtOyT3-2GRX-LYY=.abd06a49-9160-420c-90e5-fcbea1a48472@github.com>

just minor refactoring that was not integrated with fix for JDK-8334484

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

Commit messages:
 - 8353664: [lworld] missing code for fix for JDK-8334484

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

PR: https://git.openjdk.org/valhalla/pull/1415

From coleen.phillimore at oracle.com  Thu Apr  3 18:38:27 2025
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 3 Apr 2025 14:38:27 -0400
Subject: Result: New Valhalla Committer: Matias Saavedra Silva
Message-ID: <80a28ce1-603e-4886-bc9f-0d0dbc5cbbaa@oracle.com>

Voting for Matias Saavedra Silva [1] is now closed.

Yes: 6
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Coleen Phillimore

[1] https://mail.openjdk.org/pipermail/valhalla-dev/2025-March/013808.html

From qamai at openjdk.org  Fri Apr  4 04:33:34 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 4 Apr 2025 04:33:34 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v5]
In-Reply-To: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
Message-ID: <ajNMG8XhTtobKq6fyZrBq-9eMwk3088ia0O1waRlX5c=.8d9e20bf-d3e0-47d1-bed9-5e242092a97d@github.com>

> Hi,
> 
> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
> 
> Please take a look and review this PR, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  make it more explicit

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1406/files
  - new: https://git.openjdk.org/valhalla/pull/1406/files/f597c9e5..c2dc389a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=04
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=03-04

  Stats: 30 lines in 1 file changed: 13 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1406.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1406/head:pull/1406

PR: https://git.openjdk.org/valhalla/pull/1406

From thartmann at openjdk.org  Fri Apr  4 07:13:12 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 4 Apr 2025 07:13:12 GMT
Subject: [lworld] RFR: 8353212: [lworld] TestFlatArrayAliasesCardMark.java
 crashes when run with -XX:+UseAtomicValueFlattening
Message-ID: <kGGjPULOvQ6wQK2cIryseXXzZEm9nLRngB57hSYpI70=.9dbeb0a1-8fc8-48a0-9528-b9520c188836@github.com>

Code added by [JDK-8341759](https://bugs.openjdk.org/browse/JDK-8341759) needs to handle fields of type `T_ARRAY`.

Best regards,
Tobias

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

Commit messages:
 - 8353212: [lworld] TestFlatArrayAliasesCardMark.java crashes when run with -XX:+UseAtomicValueFlattening

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

PR: https://git.openjdk.org/valhalla/pull/1417

From thartmann at openjdk.org  Fri Apr  4 08:34:14 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 4 Apr 2025 08:34:14 GMT
Subject: [lworld] Integrated: 8353212: [lworld]
 TestFlatArrayAliasesCardMark.java crashes when run with
 -XX:+UseAtomicValueFlattening
In-Reply-To: <kGGjPULOvQ6wQK2cIryseXXzZEm9nLRngB57hSYpI70=.9dbeb0a1-8fc8-48a0-9528-b9520c188836@github.com>
References: <kGGjPULOvQ6wQK2cIryseXXzZEm9nLRngB57hSYpI70=.9dbeb0a1-8fc8-48a0-9528-b9520c188836@github.com>
Message-ID: <mqsebKAMa0hQla9lOCU9Vg7a4O9-nDjJryDHKz7fjXc=.d441f0b6-739e-41ef-81d8-1656eec5d9b9@github.com>

On Fri, 4 Apr 2025 07:08:36 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Code added by [JDK-8341759](https://bugs.openjdk.org/browse/JDK-8341759) needs to handle fields of type `T_ARRAY`.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: c55102a4
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c55102a4bf9bef0debeb1ffa8cabca079b02fe76
Stats:     40 lines in 2 files changed: 39 ins; 0 del; 1 mod

8353212: [lworld] TestFlatArrayAliasesCardMark.java crashes when run with -XX:+UseAtomicValueFlattening

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

PR: https://git.openjdk.org/valhalla/pull/1417

From thartmann at openjdk.org  Fri Apr  4 08:50:12 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 4 Apr 2025 08:50:12 GMT
Subject: [lworld] RFR: 8353202: [lworld] TestArrays.java crashes with
 -XX:+UseNullableValueFlattening
Message-ID: <cjRvbP1URAnB4__irXZbGRTqKuHYdCzZKZRqaAv5dYM=.a793e27d-9068-471a-b8f5-de95163792d0@github.com>

Nullable, atomic, flat arrays and fields of an empty value class should be treated as atomic by C2. Currently, C2 treats them as naturally atomic because they only have one field (the null marker).

Best regards,
Tobias

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

Commit messages:
 - 8353202: [lworld] TestArrays.java crashes with -XX:+UseNullableValueFlattening

Changes: https://git.openjdk.org/valhalla/pull/1418/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1418&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353202
  Stats: 62 lines in 5 files changed: 54 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1418.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1418/head:pull/1418

PR: https://git.openjdk.org/valhalla/pull/1418

From thartmann at openjdk.org  Fri Apr  4 10:31:07 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 4 Apr 2025 10:31:07 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v5]
In-Reply-To: <ajNMG8XhTtobKq6fyZrBq-9eMwk3088ia0O1waRlX5c=.8d9e20bf-d3e0-47d1-bed9-5e242092a97d@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <ajNMG8XhTtobKq6fyZrBq-9eMwk3088ia0O1waRlX5c=.8d9e20bf-d3e0-47d1-bed9-5e242092a97d@github.com>
Message-ID: <PkEvJqOykr_JvozCp_9BWBFOMX9DwwRDfdz0O3iUkuk=.582ca658-d909-428b-bc78-0d58df2c98ed@github.com>

On Fri, 4 Apr 2025 04:33:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
>> 
>> Please take a look and review this PR, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make it more explicit

Thanks! I'll re-run testing.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2778257246

From dsimms at openjdk.org  Fri Apr  4 11:39:42 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Apr 2025 11:39:42 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <jepKNu5-SoUUrhz8e1T4J6TsftkGisIfNexz8GWUssg=.5531cac6-fe35-473f-8a74-6ea2890d714e@github.com>

Merge jdk-25-14

Merge branch 'lworld' into lworld_merge_jdk_25_14

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_25_14
 - Adjust for 8353717
 - Merge tag 'jdk-25+14' into lworld_merge_jdk_25_14
 - 8350905: Shenandoah: Releasing a WeakHandle's referent may extend its lifetime
 - 8351699: Problem list com/sun/jdi/JdbStopInNotificationThreadTest.java with ZGC
 - 8351444: Shenandoah: Class Unloading may encounter recycled oops
 - 8351640: Print reason for making method not entrant
 - 8351142: Add JFR monitor deflation and statistics events
 - 8351881: Tidy complains about missing "alt" attribute
 - 8350982: -server|-client causes fatal exception on static JDK
 - ... and 77 more: https://git.openjdk.org/valhalla/compare/c55102a4...adab8a34

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

Changes: https://git.openjdk.org/valhalla/pull/1419/files
  Stats: 43482 lines in 623 files changed: 20465 ins; 15010 del; 8007 mod
  Patch: https://git.openjdk.org/valhalla/pull/1419.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1419/head:pull/1419

PR: https://git.openjdk.org/valhalla/pull/1419

From dsimms at openjdk.org  Fri Apr  4 11:39:43 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Apr 2025 11:39:43 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <jepKNu5-SoUUrhz8e1T4J6TsftkGisIfNexz8GWUssg=.5531cac6-fe35-473f-8a74-6ea2890d714e@github.com>
References: <jepKNu5-SoUUrhz8e1T4J6TsftkGisIfNexz8GWUssg=.5531cac6-fe35-473f-8a74-6ea2890d714e@github.com>
Message-ID: <PU7X4JzxyLCxA9c5VTcFR9U4mQZF878w_yFVfnJzH8o=.444856d3-2ddd-42f6-8538-e4ec545d83a2@github.com>

On Fri, 4 Apr 2025 11:30:48 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25-14
> 
> Merge branch 'lworld' into lworld_merge_jdk_25_14

This pull request has now been integrated.

Changeset: a8ad2753
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a8ad27534166e0956c6e5cfd4dbd0578f408cff7
Stats:     43482 lines in 623 files changed: 20465 ins; 15010 del; 8007 mod

Merge jdk

Merge jdk-25+14

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

PR: https://git.openjdk.org/valhalla/pull/1419

From fparain at openjdk.org  Fri Apr  4 17:46:01 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 4 Apr 2025 17:46:01 GMT
Subject: [lworld] RFR: 8353746: [lworld] Remove the default value and
 @ImplictlyConstructible annotation
Message-ID: <xRQMb3_T46JlU1rLIejU-fhW17CMqT0d5jwdO-6tazI=.0e18f749-e845-49d0-a8cd-53a187bb62d7@github.com>

Removal of the all-zero default value and the @ImplicitlyConstructible annotation.

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

Commit messages:
 - Merge branch 'strict_nr' of https://github.com/fparain/valhalla into strict_nr
 - Merge branch 'strict_nr' of github.com:fparain/valhalla into strict_nr
 - Comment adjustment
 - Remove the @ImplicitlyConstructible annotation
 - Update AppCDS tests
 - Merge remote-tracking branch 'upstream/lworld' into strict_nr
 - Fix comment
 - More refactoring
 - Removed null checks for null-free, non-flat fields from C2. More refactoring.
 - More refactoring
 - ... and 12 more: https://git.openjdk.org/valhalla/compare/f662357d...107478ea

Changes: https://git.openjdk.org/valhalla/pull/1389/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1389&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353746
  Stats: 4168 lines in 183 files changed: 1230 ins; 1553 del; 1385 mod
  Patch: https://git.openjdk.org/valhalla/pull/1389.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1389/head:pull/1389

PR: https://git.openjdk.org/valhalla/pull/1389

From fparain at openjdk.org  Fri Apr  4 19:19:09 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 4 Apr 2025 19:19:09 GMT
Subject: [lworld] Integrated: 8353746: [lworld] Remove the default value and
 @ImplictlyConstructible annotation
In-Reply-To: <xRQMb3_T46JlU1rLIejU-fhW17CMqT0d5jwdO-6tazI=.0e18f749-e845-49d0-a8cd-53a187bb62d7@github.com>
References: <xRQMb3_T46JlU1rLIejU-fhW17CMqT0d5jwdO-6tazI=.0e18f749-e845-49d0-a8cd-53a187bb62d7@github.com>
Message-ID: <qj4kv_uEqTv960b9nqdBZHY-TsBuIWh7fBs2NAkUmRc=.6b8efe74-1297-4a48-9139-72d2430580ac@github.com>

On Tue, 4 Mar 2025 14:58:51 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Removal of the all-zero default value and the @ImplicitlyConstructible annotation.

This pull request has now been integrated.

Changeset: 293a9c40
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/293a9c406f784c1d8d165574487e58c475739074
Stats:     4168 lines in 183 files changed: 1230 ins; 1553 del; 1385 mod

8353746: [lworld] Remove the default value and @ImplictlyConstructible annotation

Co-authored-by: Tobias Hartmann <thartmann at openjdk.org>
Co-authored-by: Roger Riggs <rriggs at openjdk.org>

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

PR: https://git.openjdk.org/valhalla/pull/1389

From fparain at openjdk.org  Fri Apr  4 20:52:06 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 4 Apr 2025 20:52:06 GMT
Subject: [lworld] Integrated: Remove last use of the default value
Message-ID: <StHcyJs7nuTcm9fvkA8x3RvGPRn2alEy1-M20hteBak=.221bff55-7fec-41cd-b761-0384094d3aa7@github.com>

Remove last use of the default value that came from a last minute merge.

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

Commit messages:
 - Remove cases with default value

Changes: https://git.openjdk.org/valhalla/pull/1420/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1420&range=00
  Stats: 10 lines in 1 file changed: 2 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1420.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1420/head:pull/1420

PR: https://git.openjdk.org/valhalla/pull/1420

From fparain at openjdk.org  Fri Apr  4 20:52:06 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 4 Apr 2025 20:52:06 GMT
Subject: [lworld] Integrated: Remove last use of the default value
In-Reply-To: <StHcyJs7nuTcm9fvkA8x3RvGPRn2alEy1-M20hteBak=.221bff55-7fec-41cd-b761-0384094d3aa7@github.com>
References: <StHcyJs7nuTcm9fvkA8x3RvGPRn2alEy1-M20hteBak=.221bff55-7fec-41cd-b761-0384094d3aa7@github.com>
Message-ID: <FJI8nZPU160ScGH9dAxHegYRLNcSrw3SaO4yPKELAlU=.89630d7a-262e-4364-8e44-b98e53f14bc3@github.com>

On Fri, 4 Apr 2025 20:46:36 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove last use of the default value that came from a last minute merge.

This pull request has now been integrated.

Changeset: 4f7decde
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4f7decde6538902d4bedebd0497d8123d5fb9e27
Stats:     10 lines in 1 file changed: 2 ins; 7 del; 1 mod

Remove last use of the default value

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

PR: https://git.openjdk.org/valhalla/pull/1420

From fparain at openjdk.org  Fri Apr  4 21:36:34 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 4 Apr 2025 21:36:34 GMT
Subject: [lworld] Integrated: 8353752: [lworld] Remove handcoded offsets of
 field offsets for boxing classes
Message-ID: <PFdAlaXkRrZGY8-TsFcVyF3rg0WnQa6Ff5RStEy3Q8Q=.71d97f17-8234-4e46-a0ae-0fa7e1b29ba8@github.com>

Remove hand coded offsets of boxing classes.

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

Commit messages:
 - Remove hand code offets of boxing classes

Changes: https://git.openjdk.org/valhalla/pull/1421/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1421&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353752
  Stats: 68 lines in 2 files changed: 8 ins; 12 del; 48 mod
  Patch: https://git.openjdk.org/valhalla/pull/1421.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1421/head:pull/1421

PR: https://git.openjdk.org/valhalla/pull/1421

From fparain at openjdk.org  Fri Apr  4 21:36:34 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 4 Apr 2025 21:36:34 GMT
Subject: [lworld] Integrated: 8353752: [lworld] Remove handcoded offsets of
 field offsets for boxing classes
In-Reply-To: <PFdAlaXkRrZGY8-TsFcVyF3rg0WnQa6Ff5RStEy3Q8Q=.71d97f17-8234-4e46-a0ae-0fa7e1b29ba8@github.com>
References: <PFdAlaXkRrZGY8-TsFcVyF3rg0WnQa6Ff5RStEy3Q8Q=.71d97f17-8234-4e46-a0ae-0fa7e1b29ba8@github.com>
Message-ID: <tw4w6khxnyvpPeNetgHS7aQyGFQwFjj_GdOL3iLhAzc=.fa3f7b91-6790-471f-9c44-e22c89d778f4@github.com>

On Fri, 4 Apr 2025 21:29:50 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove hand coded offsets of boxing classes.

This pull request has now been integrated.

Changeset: a85d0a25
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a85d0a25d10d1dd2158b0483e38f547f9564cd39
Stats:     68 lines in 2 files changed: 8 ins; 12 del; 48 mod

8353752: [lworld] Remove handcoded offsets of field offsets for boxing classes

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

PR: https://git.openjdk.org/valhalla/pull/1421

From thartmann at openjdk.org  Mon Apr  7 05:27:01 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Apr 2025 05:27:01 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v5]
In-Reply-To: <ajNMG8XhTtobKq6fyZrBq-9eMwk3088ia0O1waRlX5c=.8d9e20bf-d3e0-47d1-bed9-5e242092a97d@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <ajNMG8XhTtobKq6fyZrBq-9eMwk3088ia0O1waRlX5c=.8d9e20bf-d3e0-47d1-bed9-5e242092a97d@github.com>
Message-ID: <HLTjAsvDU0u878ty1-lcZteYscCFehpgTKfB4MRlX90=.e4ffd247-7e81-43db-9594-f5b22dc69aa8@github.com>

On Fri, 4 Apr 2025 04:33:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
>> 
>> Please take a look and review this PR, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make it more explicit

All tests passed. The changes look good to me.

src/hotspot/share/opto/library_call.cpp line 2669:

> 2667:   const Type* type = gvn().type(value);
> 2668:   if (!type->is_inlinetypeptr()) {
> 2669:     C->record_method_not_compilable("value passed to Unsafe::makePrivateBuffer is not of a constant value type");

Do we really need to make the method non-compilable?

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1406#pullrequestreview-2716296970
PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2013631996

From thartmann at openjdk.org  Mon Apr  7 05:27:01 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Apr 2025 05:27:01 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v5]
In-Reply-To: <Gw4MeykdMFPQC6ro0o6uemU3hQnUp8Q5wgeBUejzJvc=.a0d2d488-94b8-45c6-bb32-bc01e955064a@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <n_ogFfQMayVj3y812--lluzONsHioN1JfvPipLGBOD4=.e6dd365b-3ef0-4d7d-bee9-7392f9a62dd4@github.com>
 <Gw4MeykdMFPQC6ro0o6uemU3hQnUp8Q5wgeBUejzJvc=.a0d2d488-94b8-45c6-bb32-bc01e955064a@github.com>
Message-ID: <qjbLcKtvU8mfw3srZTIFGI3apFg5fRTQMTY-rH_dbvE=.cf673591-38ad-431d-9715-ac90002dd304@github.com>

On Wed, 26 Mar 2025 03:16:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 2685:
>> 
>>> 2683:   ciInlineKlass* vk = type->inline_klass();
>>> 2684:   Node* klass = makecon(TypeKlassPtr::make(vk));
>>> 2685:   Node* obj = new_instance(klass);
>> 
>> We have adpoted a similar strategy in lworld-vector 
>> 
>> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1071
>
> We should also emit the IR to mark the larval bit in the object header.
> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1075

I wonder if we really still need the larval bit? Does it have any use other than in assertions?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2013644219

From qamai at openjdk.org  Mon Apr  7 06:44:12 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 7 Apr 2025 06:44:12 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v5]
In-Reply-To: <qjbLcKtvU8mfw3srZTIFGI3apFg5fRTQMTY-rH_dbvE=.cf673591-38ad-431d-9715-ac90002dd304@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <n_ogFfQMayVj3y812--lluzONsHioN1JfvPipLGBOD4=.e6dd365b-3ef0-4d7d-bee9-7392f9a62dd4@github.com>
 <Gw4MeykdMFPQC6ro0o6uemU3hQnUp8Q5wgeBUejzJvc=.a0d2d488-94b8-45c6-bb32-bc01e955064a@github.com>
 <qjbLcKtvU8mfw3srZTIFGI3apFg5fRTQMTY-rH_dbvE=.cf673591-38ad-431d-9715-ac90002dd304@github.com>
Message-ID: <fnc2aDd9zgjrZrq0Qz6J5VMvV_VyC317ym0sKTXpxB8=.63031036-4ae0-493b-92ad-25202c858b46@github.com>

On Wed, 26 Mar 2025 08:48:53 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> We should also emit the IR to mark the larval bit in the object header.
>> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1075
>
> I wonder if we really still need the larval bit? Does it have any use other than in assertions?

@TobiHartmann I'm not sure, currently the larval bit does not seem to have any use, but maybe in the future the runtime could try to deduplicate value objects. In that case, IMO we don't actually need to have an exact value of the larval-ness but only a conservative value answering the question "Is this object definitely a non-larval value object?"

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2030548372

From qamai at openjdk.org  Mon Apr  7 06:53:04 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 7 Apr 2025 06:53:04 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v5]
In-Reply-To: <PkEvJqOykr_JvozCp_9BWBFOMX9DwwRDfdz0O3iUkuk=.582ca658-d909-428b-bc78-0d58df2c98ed@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <ajNMG8XhTtobKq6fyZrBq-9eMwk3088ia0O1waRlX5c=.8d9e20bf-d3e0-47d1-bed9-5e242092a97d@github.com>
 <PkEvJqOykr_JvozCp_9BWBFOMX9DwwRDfdz0O3iUkuk=.582ca658-d909-428b-bc78-0d58df2c98ed@github.com>
Message-ID: <UL_OoL7M7QQas-g1YyvBGj0Q1y_5Na2ZpCg7oArvSco=.40a6c8b3-653a-4563-b54a-3b66eadf994f@github.com>

On Fri, 4 Apr 2025 10:28:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make it more explicit
>
> Thanks! I'll re-run testing.

@TobiHartmann Thanks a lot for your reviews and testings.

> src/hotspot/share/opto/library_call.cpp line 2669:
> 
>> 2667:   const Type* type = gvn().type(value);
>> 2668:   if (!type->is_inlinetypeptr()) {
>> 2669:     C->record_method_not_compilable("value passed to Unsafe::makePrivateBuffer is not of a constant value type");
> 
> Do we really need to make the method non-compilable?

I think it is better to be conservative, `Unsafe` is a niche and its uses are mostly with a concrete value type so in the rare cases, bailing out would be a safe option. We can definitely relax this restriction afterward if the need arises.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2782199100
PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2030559035

From duke at openjdk.org  Mon Apr  7 06:53:04 2025
From: duke at openjdk.org (duke)
Date: Mon, 7 Apr 2025 06:53:04 GMT
Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics [v5]
In-Reply-To: <ajNMG8XhTtobKq6fyZrBq-9eMwk3088ia0O1waRlX5c=.8d9e20bf-d3e0-47d1-bed9-5e242092a97d@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
 <ajNMG8XhTtobKq6fyZrBq-9eMwk3088ia0O1waRlX5c=.8d9e20bf-d3e0-47d1-bed9-5e242092a97d@github.com>
Message-ID: <8kO5mQeCzo7PWKkCDODuv9wBzzkVXO0YXaAmn8dV4mk=.e4fd1369-bfb4-4aba-8deb-1e660645bfe0@github.com>

On Fri, 4 Apr 2025 04:33:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
>> 
>> Please take a look and review this PR, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make it more explicit

@merykitty 
Your change (at version c2dc389ad6a2eb34bf2e2bf7062b24eb3bf14df5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2782200512

From qamai at openjdk.org  Mon Apr  7 07:17:09 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 7 Apr 2025 07:17:09 GMT
Subject: [lworld] Integrated: 8352647: [lworld] Remove larval InlineTypeNode in
 Unsafe intrinsics
In-Reply-To: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
References: <b7mcS-hfZy7fk4Ojoma89jKDvx5HXt9viGBLm-pS9XE=.a8fd7b40-d1b7-4e91-ae72-4471d503baa2@github.com>
Message-ID: <Y1lA4imgwo2ZVhsbRxnDHmzhI3evyIuozWf9Ywc-Oek=.dc1489a9-1f9e-4e7e-9cc5-7f40094a3140@github.com>

On Sun, 23 Mar 2025 17:21:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors.
> 
> Please take a look and review this PR, thanks a lot.

This pull request has now been integrated.

Changeset: 0bbfece8
Author:    Quan Anh Mai <qamai at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0bbfece897944f0f25e0d45fc8a4027d3828efde
Stats:     100 lines in 4 files changed: 81 ins; 2 del; 17 mod

8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics

Reviewed-by: jbhateja, thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1406

From thartmann at openjdk.org  Mon Apr  7 13:31:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Apr 2025 13:31:37 GMT
Subject: [lworld] RFR: 8353202: [lworld] TestArrays.java crashes with
 -XX:+UseNullableValueFlattening [v2]
In-Reply-To: <cjRvbP1URAnB4__irXZbGRTqKuHYdCzZKZRqaAv5dYM=.a793e27d-9068-471a-b8f5-de95163792d0@github.com>
References: <cjRvbP1URAnB4__irXZbGRTqKuHYdCzZKZRqaAv5dYM=.a793e27d-9068-471a-b8f5-de95163792d0@github.com>
Message-ID: <9FHg82DJss5Q5TQOWP-FARRuLQY5t3dtmhWM6nMGEoA=.e3656635-e796-45fa-b064-8c73f7371274@github.com>

> Nullable, atomic, flat arrays and fields of an empty value class should be treated as atomic by C2. Currently, C2 treats them as naturally atomic because they only have one field (the null marker).
> 
> The changes in `src/hotspot/share/c1/c1_LIRGenerator.cpp` are unrelated to this and serve as a temporary workaround for [JDK-8353851](https://bugs.openjdk.org/browse/JDK-8353851) which I found with my new tests.
> 
> Best regards,
> 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 three additional commits since the last revision:

 - Workaround for JDK-8353851
 - Merge branch 'lworld' into JDK-8353202
 - 8353202: [lworld] TestArrays.java crashes with -XX:+UseNullableValueFlattening

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1418/files
  - new: https://git.openjdk.org/valhalla/pull/1418/files/9f65ab2b..98f0e550

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1418&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1418&range=00-01

  Stats: 47733 lines in 796 files changed: 21709 ins; 16580 del; 9444 mod
  Patch: https://git.openjdk.org/valhalla/pull/1418.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1418/head:pull/1418

PR: https://git.openjdk.org/valhalla/pull/1418

From fparain at openjdk.org  Mon Apr  7 14:44:30 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 7 Apr 2025 14:44:30 GMT
Subject: [lworld] RFR: 8336795: [lworld] JNI MonitorEnter doesn't return the
 right value when it throws an exception
Message-ID: <nRQF0jzYdfvLH5meQ5P_4P5ViVKDsj3iQCD0_XK61QY=.064de74b-be1d-4ed4-962c-d33a6664828b@github.com>

Fix the value returned by JNI MonitorEnter when called on a value class instance.

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

Commit messages:
 - Fix value return by JNI MonitorEnter

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

PR: https://git.openjdk.org/valhalla/pull/1422

From fparain at openjdk.org  Mon Apr  7 15:54:16 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 7 Apr 2025 15:54:16 GMT
Subject: [lworld] Integrated: 8336795: [lworld] JNI MonitorEnter doesn't return
 the right value when it throws an exception
In-Reply-To: <nRQF0jzYdfvLH5meQ5P_4P5ViVKDsj3iQCD0_XK61QY=.064de74b-be1d-4ed4-962c-d33a6664828b@github.com>
References: <nRQF0jzYdfvLH5meQ5P_4P5ViVKDsj3iQCD0_XK61QY=.064de74b-be1d-4ed4-962c-d33a6664828b@github.com>
Message-ID: <3qvFSlxrHsf8lzPwJkGoIzT6nPs2IzHLGe2y7y3x4OE=.d5a47e16-3a93-4a62-92a6-1a32a7ed034c@github.com>

On Mon, 7 Apr 2025 14:37:36 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix the value returned by JNI MonitorEnter when called on a value class instance.

This pull request has now been integrated.

Changeset: f48c0f45
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f48c0f45a0a15ca4b40329469f247449bfee0538
Stats:     9 lines in 3 files changed: 7 ins; 0 del; 2 mod

8336795: [lworld] JNI MonitorEnter doesn't return the right value when it throws an exception

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

PR: https://git.openjdk.org/valhalla/pull/1422

From thartmann at openjdk.org  Tue Apr  8 06:05:23 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 8 Apr 2025 06:05:23 GMT
Subject: [lworld] Integrated: 8353202: [lworld] TestArrays.java crashes with
 -XX:+UseNullableValueFlattening
In-Reply-To: <cjRvbP1URAnB4__irXZbGRTqKuHYdCzZKZRqaAv5dYM=.a793e27d-9068-471a-b8f5-de95163792d0@github.com>
References: <cjRvbP1URAnB4__irXZbGRTqKuHYdCzZKZRqaAv5dYM=.a793e27d-9068-471a-b8f5-de95163792d0@github.com>
Message-ID: <9acT5g6bwkdCBLiDWv8r9N8wA6gHD36P86aWxZzO0W0=.6d3dc16a-aff4-4b43-8606-508308bdbc3b@github.com>

On Fri, 4 Apr 2025 08:45:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Nullable, atomic, flat arrays and fields of an empty value class should be treated as atomic by C2. Currently, C2 treats them as naturally atomic because they only have one field (the null marker).
> 
> The changes in `src/hotspot/share/c1/c1_LIRGenerator.cpp` are unrelated to this and serve as a temporary workaround for [JDK-8353851](https://bugs.openjdk.org/browse/JDK-8353851) which I found with my new tests.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: b5395e82
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b5395e82b1cce79d3139917b6d151f99ca90ee91
Stats:     72 lines in 6 files changed: 61 ins; 1 del; 10 mod

8353202: [lworld] TestArrays.java crashes with -XX:+UseNullableValueFlattening

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

PR: https://git.openjdk.org/valhalla/pull/1418

From dsimms at openjdk.org  Tue Apr  8 08:38:32 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 8 Apr 2025 08:38:32 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <mBy12cP1Ub6UP2jbuQzA1KvKFe2riB8-53U1FU-ldu0=.b377998d-5cc3-4ae5-a820-387e089fae52@github.com>

Merge tag 'jdk-25+15' into lworld_merge_jdk_25_15
Added tag jdk-25+15 for changeset 74df384a

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

Commit messages:
 - Merge tag 'jdk-25+15' into lworld_merge_jdk_25_15
 - 8352428: GenShen: Old-gen cycles are still looping
 - 8350813: Rendering of bulky sound bank from MIDI sequence can cause OutOfMemoryError
 - 8350589: Investigate cleaner implementation of AArch64 ML-DSA intrinsic introduced in JDK-8348561
 - 8350898: Shenandoah: Eliminate final roots safepoint
 - 8351969: Add Public Identifiers to the JDK built-in Catalog
 - 8352109: java/awt/Desktop/MailTest.java fails in platforms where Action.MAIL is not supported
 - 8351933: Inaccurate masking of TC subfield decrement in ForkJoinPool
 - 8350485: C2: factor out common code in Node::grow() and Node::out_grow()
 - 8351902: RISC-V: Several tests fail after JDK-8351145
 - ... and 73 more: https://git.openjdk.org/valhalla/compare/b5395e82...4d0d674e

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

Changes: https://git.openjdk.org/valhalla/pull/1423/files
  Stats: 16396 lines in 378 files changed: 9152 ins; 4430 del; 2814 mod
  Patch: https://git.openjdk.org/valhalla/pull/1423.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1423/head:pull/1423

PR: https://git.openjdk.org/valhalla/pull/1423

From qamai at openjdk.org  Tue Apr  8 19:23:23 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 8 Apr 2025 19:23:23 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
Message-ID: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>

Hi,

When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.

Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - add tests
 - fold strict final field loads

Changes: https://git.openjdk.org/valhalla/pull/1424/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354068
  Stats: 228 lines in 2 files changed: 209 ins; 1 del; 18 mod
  Patch: https://git.openjdk.org/valhalla/pull/1424.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1424/head:pull/1424

PR: https://git.openjdk.org/valhalla/pull/1424

From liach at openjdk.org  Tue Apr  8 20:29:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 20:29:31 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <gpOm4EeebceNyheVeIlMdz9eku9U7O6dBz-oNpwH_Lg=.a720d7bf-abec-43c5-a00e-89e9469dfc1d@github.com>

On Tue, 8 Apr 2025 19:17:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Just curious, how is a strict final load distinct from a stable/trusted final load?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2787583161

From qamai at openjdk.org  Tue Apr  8 21:12:31 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 8 Apr 2025 21:12:31 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <6CTnbTbluGgPLDWjLTkVaagw3-RRgGJi9jzZUbWutHA=.08c949b7-db0b-4038-a59f-16b600492c8d@github.com>

On Tue, 8 Apr 2025 19:17:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Although, we can say that trusted fields are in trusted class which should not leak instances before the completion of the constructor, and probably a weaker version of this could be ported to those trusted fields. I think making those fields strict instead would be a better move. The fact that an object must initialize all its strict final fields before we can do anything with it is a really strong guarantee that makes reasoning much easier, especially when we have to deal with concurrent accesses.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2787669735

From liach at openjdk.org  Tue Apr  8 21:27:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 21:27:24 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <aI2w11CtQPqBvEEbuPeUqyxWQ8KFxo2I_PYG3yVbCM0=.6d7fa1d7-7f95-403a-bb52-cdeed1d43fd4@github.com>

On Tue, 8 Apr 2025 19:17:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Can this strict trusting be upstreamed to mainline as soon as the strict fields are available, without waiting for value objects?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2787697369

From forax at openjdk.org  Tue Apr  8 21:52:04 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 8 Apr 2025 21:52:04 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <iuOwXlXYbBD4kxP5SXmXz0VsHlaBT3e8mm_ypa5jxc0=.93ad9ba9-69eb-43fd-8a7a-335eab7b4405@github.com>

On Tue, 8 Apr 2025 19:17:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

That's the plan, see
  https://openjdk.org/jeps/8350458

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2787738697

From dsimms at openjdk.org  Wed Apr  9 05:23:47 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 9 Apr 2025 05:23:47 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <mBy12cP1Ub6UP2jbuQzA1KvKFe2riB8-53U1FU-ldu0=.b377998d-5cc3-4ae5-a820-387e089fae52@github.com>
References: <mBy12cP1Ub6UP2jbuQzA1KvKFe2riB8-53U1FU-ldu0=.b377998d-5cc3-4ae5-a820-387e089fae52@github.com>
Message-ID: <UqhO5ph5iF92rsreM0xNvndnst4suuJC82tg3wDuDZo=.b9dbd8d7-bdc9-4086-afef-1fbf1efcf678@github.com>

On Tue, 8 Apr 2025 08:32:07 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+15' into lworld_merge_jdk_25_15
> Added tag jdk-25+15 for changeset 74df384a

This pull request has now been integrated.

Changeset: ea9789ce
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ea9789ce9cce9da4deaa514090cf256001151060
Stats:     16396 lines in 378 files changed: 9152 ins; 4430 del; 2814 mod

Merge jdk

Merge jdk-25+15

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

PR: https://git.openjdk.org/valhalla/pull/1423

From qamai at openjdk.org  Wed Apr  9 06:37:43 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 9 Apr 2025 06:37:43 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>

On Tue, 8 Apr 2025 19:17:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Note that the objects are still not scalarized due to a bug. When we try to decide if the return will unnecessarily keep the oop of an `InlineTypeNode` alive, we fail to consider the case that some outputs of the oop are memory barriers.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2788456141

From liach at openjdk.org  Wed Apr  9 09:48:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 09:48:24 GMT
Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing
 [v4]
In-Reply-To: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com>
References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com>
Message-ID: <vbi5aKK1kZgubPzkdygbHknG2raWriFpA0Dpuoqewk4=.fd0ad242-88f6-407d-8a4f-5cf143d7609c@github.com>

> Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Rollback to the jdk internal strict annotation
 - Revert back to the jdk internal strict
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/strict-processor
 - Fix a bug and enhance tests
 - Add very primitive super rewrite functionality
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/strict-processor
 - 8351362: Post-process @Strict annotation for testing

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

Changes: https://git.openjdk.org/valhalla/pull/1395/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1395&range=03
  Stats: 444 lines in 6 files changed: 440 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1395.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1395/head:pull/1395

PR: https://git.openjdk.org/valhalla/pull/1395

From liach at openjdk.org  Wed Apr  9 10:09:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 10:09:27 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v3]
In-Reply-To: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
Message-ID: <LkcINe9tWzoi4dURMNjclG3gjYzmpy01mN1f2dk56DM=.5b271e21-112d-438d-b1df-f3364a3a0747@github.com>

> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
> 
> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.

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

 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/vo-obj-getters
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/vo-obj-getters
 - Fix redundant debug and failing IO test
 - 8348606: [lworld] Substitutability test may perform heap allocations

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1364/files
  - new: https://git.openjdk.org/valhalla/pull/1364/files/4d6a7d5c..ae2c70ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1364&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1364&range=01-02

  Stats: 157312 lines in 3353 files changed: 76372 ins; 55017 del; 25923 mod
  Patch: https://git.openjdk.org/valhalla/pull/1364.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1364/head:pull/1364

PR: https://git.openjdk.org/valhalla/pull/1364

From qamai at openjdk.org  Wed Apr  9 10:09:27 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 9 Apr 2025 10:09:27 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v2]
In-Reply-To: <Il9Yb3IDQPRrBpnyR-sF4FCXei7SBxfwP0DQL3ofmaY=.ce9727fb-cfc6-4d91-929e-6534cba69572@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
 <Il9Yb3IDQPRrBpnyR-sF4FCXei7SBxfwP0DQL3ofmaY=.ce9727fb-cfc6-4d91-929e-6534cba69572@github.com>
Message-ID: <c9gn4tJO63S2n28A7SObkowjxzfOCGdmME1TaQL6oV0=.c3d485d6-f0f4-4f4b-a9f5-042454b987b5@github.com>

On Thu, 13 Feb 2025 01:17:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
>> 
>> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix redundant debug and failing IO test

The reason you are seeing the failures is that you are using `Unsafe` incorrectly. Note this paragraph:

     * The results are undefined unless one of the following cases is true:
     * <ul>
     * <li>The offset was obtained from {@link #objectFieldOffset} on
     * the {@link java.lang.reflect.Field} of some Java field and the object
     * referred to by {@code o} is of a class compatible with that
     * field's class.
     *
     * <li>The offset and object reference {@code o} (either null or
     * non-null) were both obtained via {@link #staticFieldOffset}
     * and {@link #staticFieldBase} (respectively) from the
     * reflective {@link Field} representation of some Java field.
     *
     * <li>The object referred to by {@code o} is an array, and the offset
     * is an integer of the form {@code B+N*S}, where {@code N} is
     * a valid index into the array, and {@code B} and {@code S} are
     * the values obtained by {@link #arrayBaseOffset} and {@link
     * #arrayIndexScale} (respectively) from the array's class.  The value
     * referred to is the {@code N}<em>th</em> element of the array.
     *
     * </ul>

The wording here is albeit bad, it is not only the result that is undefined, the behaviour itself is undefined.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1364#issuecomment-2656802521

From liach at openjdk.org  Wed Apr  9 10:09:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 10:09:28 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v2]
In-Reply-To: <Il9Yb3IDQPRrBpnyR-sF4FCXei7SBxfwP0DQL3ofmaY=.ce9727fb-cfc6-4d91-929e-6534cba69572@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
 <Il9Yb3IDQPRrBpnyR-sF4FCXei7SBxfwP0DQL3ofmaY=.ce9727fb-cfc6-4d91-929e-6534cba69572@github.com>
Message-ID: <PKOeJeZaYr0_9jkDphoDbLwV6b_5fbxWoY6OtCfbaNQ=.e261508d-8b7e-4c06-9c03-380fac02bae3@github.com>

On Thu, 13 Feb 2025 01:17:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
>> 
>> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix redundant debug and failing IO test

Hmm, @fparain recommends this access pattern for me...

Marking this ready - @TobiHartmann recommends me to integrate and C2 to subsequently fix up. This can fix JDK-8354122.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1364#issuecomment-2657028106
PR Comment: https://git.openjdk.org/valhalla/pull/1364#issuecomment-2789125586

From liach at openjdk.org  Wed Apr  9 12:41:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 12:41:09 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v4]
In-Reply-To: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
Message-ID: <kGsszoebpBCNOksMn-5MfIUfR_0HvC-xVC2FQp4q9v8=.d42f0404-29ee-4c38-afa4-56918b8fdfd3@github.com>

> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
> 
> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix failing compiler tests, thanks to @TobiHartmann

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1364/files
  - new: https://git.openjdk.org/valhalla/pull/1364/files/ae2c70ee..0e02b94f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1364&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1364&range=02-03

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1364.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1364/head:pull/1364

PR: https://git.openjdk.org/valhalla/pull/1364

From liach at openjdk.org  Wed Apr  9 12:52:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 12:52:14 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v5]
In-Reply-To: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
Message-ID: <t4yHvokFe2K0rRPIfbkCLS-PT_ugD4Rft-AYZ2EzwnE=.889d6569-5fa8-4cac-a329-f5ec3dd8e13f@github.com>

> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
> 
> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Remove obsolete annotation

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1364/files
  - new: https://git.openjdk.org/valhalla/pull/1364/files/0e02b94f..921a8d59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1364&range=04
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1364&range=03-04

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

PR: https://git.openjdk.org/valhalla/pull/1364

From thartmann at openjdk.org  Wed Apr  9 13:20:39 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 9 Apr 2025 13:20:39 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>
Message-ID: <vcLx2j01ks5YVNenT_7iW79rFf3-r8lWs8zSs5HeVbQ=.53a828a0-9ce3-4c9a-b7ac-d76c0ab34eba@github.com>

On Wed, 9 Apr 2025 06:35:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Note that the objects are still not scalarized due to a bug. When we try to decide if the return will unnecessarily keep the oop of an `InlineTypeNode` alive, we fail to consider the case that some outputs of the oop are memory barriers.

Thanks for working on this @merykitty. I haven't looked at the changes in detail yet but I see some failures in testing.


compiler/valhalla/inlinetypes/TestArrays.java
-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true

#  Internal Error (/workspace/open/src/hotspot/share/opto/node.hpp:913), pid=1752475, tid=1752491
#  assert(is_CallJava()) failed: invalid node class: Unlock
#
# JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-09-0511154.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-09-0511154.tobias.hartmann.valhalla2, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x15613fc]  optimize_strict_final_load_memory_from_local_object(ciField*, ProjNode*)+0x43c


compiler/valhalla/inlinetypes/TestFieldNullMarkers.java
-XX:-UseTLAB -DVerifyIR=false

java.lang.RuntimeException: assertEquals expected: null but was: x = -79
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:195)
	at jdk.test.lib.Asserts.assertEQ(Asserts.java:172)
	at compiler.valhalla.inlinetypes.TestFieldNullMarkers.main(TestFieldNullMarkers.java:799)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2789673996

From qamai at openjdk.org  Wed Apr  9 13:23:31 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 9 Apr 2025 13:23:31 GMT
Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla
 Unsafe intrinsics
Message-ID: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>

Hi,

This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`.

Please take a look and leave your suggestions, thanks a lot.

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

Commit messages:
 - specify undefined behavior and Valhalla intrinsics

Changes: https://git.openjdk.org/valhalla/pull/1425/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353236
  Stats: 70 lines in 1 file changed: 60 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/1425.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1425/head:pull/1425

PR: https://git.openjdk.org/valhalla/pull/1425

From liach at openjdk.org  Wed Apr  9 14:05:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 14:05:48 GMT
Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla
 Unsafe intrinsics
In-Reply-To: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
Message-ID: <pZBR-MfU0ITuhToCSEUTxc5ludzWqWiVZlbyDzGsRqg=.991e0d7e-997c-46ba-ad0c-68538aeca03f@github.com>

On Wed, 9 Apr 2025 13:18:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`.
> 
> Please take a look and leave your suggestions, thanks a lot.

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 73:

> 71:  * control path may eventually reach an invocation of an {@code Unsafe} method
> 72:  * with illegal arguments, the symptoms of undefined behavior may be present
> 73:  * even before the invocation of the {@code Unsafe} method.

I think you can talk in a more JIT-oriented manner, that while Unsafe is mostly set up to be the hooks between core libraries and hotspot runtime, hotspot compiler may interpret the input values and perform aggressive optimizations with contracts that cannot be explicitly expressed by Java program semantics.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2035449310

From qamai at openjdk.org  Wed Apr  9 17:46:35 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 9 Apr 2025 17:46:35 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - fix wrong results
 - fix invalid node class: Unlock

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1424/files
  - new: https://git.openjdk.org/valhalla/pull/1424/files/61ee5eb4..b2601380

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1424.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1424/head:pull/1424

PR: https://git.openjdk.org/valhalla/pull/1424

From qamai at openjdk.org  Wed Apr  9 17:46:35 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 9 Apr 2025 17:46:35 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <vcLx2j01ks5YVNenT_7iW79rFf3-r8lWs8zSs5HeVbQ=.53a828a0-9ce3-4c9a-b7ac-d76c0ab34eba@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>
 <vcLx2j01ks5YVNenT_7iW79rFf3-r8lWs8zSs5HeVbQ=.53a828a0-9ce3-4c9a-b7ac-d76c0ab34eba@github.com>
Message-ID: <xhAW7knLltaYj5VXEMEwneA8kXKbg4RmqMb5p9jAIwA=.f742e8b5-d893-4ba3-95cd-d0a403fc5db1@github.com>

On Wed, 9 Apr 2025 13:17:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Note that the objects are still not scalarized due to a bug. When we try to decide if the return will unnecessarily keep the oop of an `InlineTypeNode` alive, we fail to consider the case that some outputs of the oop are memory barriers.
>
> Thanks for working on this @merykitty. I haven't looked at the changes in detail yet but I see some failures in testing.
> 
> 
> compiler/valhalla/inlinetypes/TestArrays.java
> -Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true
> 
> #  Internal Error (/workspace/open/src/hotspot/share/opto/node.hpp:913), pid=1752475, tid=1752491
> #  assert(is_CallJava()) failed: invalid node class: Unlock
> #
> # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-09-0511154.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-09-0511154.tobias.hartmann.valhalla2, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x15613fc]  optimize_strict_final_load_memory_from_local_object(ciField*, ProjNode*)+0x43c
> 
> 
> compiler/valhalla/inlinetypes/TestFieldNullMarkers.java
> -XX:-UseTLAB -DVerifyIR=false
> 
> java.lang.RuntimeException: assertEquals expected: null but was: x = -79
> 	at jdk.test.lib.Asserts.fail(Asserts.java:715)
> 	at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
> 	at jdk.test.lib.Asserts.assertEquals(Asserts.java:195)
> 	at jdk.test.lib.Asserts.assertEQ(Asserts.java:172)
> 	at compiler.valhalla.inlinetypes.TestFieldNullMarkers.main(TestFieldNullMarkers.java:799)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)

@TobiHartmann Thanks a lot for the testing, the first issue is due to me using the wrong method, while the second one is due to me overlooking the existence of the graph after macro expansion. The solution for the second issue is to stop trying the transformation after macro expansion.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2790491413

From liach at openjdk.org  Wed Apr  9 18:17:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 18:17:52 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v5]
In-Reply-To: <t4yHvokFe2K0rRPIfbkCLS-PT_ugD4Rft-AYZ2EzwnE=.889d6569-5fa8-4cac-a329-f5ec3dd8e13f@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
 <t4yHvokFe2K0rRPIfbkCLS-PT_ugD4Rft-AYZ2EzwnE=.889d6569-5fa8-4cac-a329-f5ec3dd8e13f@github.com>
Message-ID: <YfBzh2v3PcGD6iDuvI7o4BrRfLDomVw-OHup-G1YSAg=.1cdfbbfb-052b-4d91-b9e5-854eb9f62952@github.com>

On Wed, 9 Apr 2025 12:52:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
>> 
>> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove obsolete annotation

`compiler/valhalla/inlinetypes/TestNullableInlineTypes.java` seems to have some problem with aarch64 with `-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation` flags on mac and linux, but I don't know what exactly causes it. No other failure. Guess I am integrating for now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1364#issuecomment-2790559502

From duke at openjdk.org  Wed Apr  9 18:17:52 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Apr 2025 18:17:52 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v5]
In-Reply-To: <t4yHvokFe2K0rRPIfbkCLS-PT_ugD4Rft-AYZ2EzwnE=.889d6569-5fa8-4cac-a329-f5ec3dd8e13f@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
 <t4yHvokFe2K0rRPIfbkCLS-PT_ugD4Rft-AYZ2EzwnE=.889d6569-5fa8-4cac-a329-f5ec3dd8e13f@github.com>
Message-ID: <l3sF1cyIUk8VlZc6zrhD16052iVbGnlOwUbP3aYZn4c=.7327876f-7582-49fd-82b2-6c4e263ccaa3@github.com>

On Wed, 9 Apr 2025 12:52:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
>> 
>> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove obsolete annotation

@liach 
Your change (at version 921a8d59961f46b0e29f5bd08644556d0eff3360) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1364#issuecomment-2790561774

From qamai at openjdk.org  Thu Apr 10 05:33:40 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 10 Apr 2025 05:33:40 GMT
Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla
 Unsafe intrinsics [v2]
In-Reply-To: <pZBR-MfU0ITuhToCSEUTxc5ludzWqWiVZlbyDzGsRqg=.991e0d7e-997c-46ba-ad0c-68538aeca03f@github.com>
References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
 <pZBR-MfU0ITuhToCSEUTxc5ludzWqWiVZlbyDzGsRqg=.991e0d7e-997c-46ba-ad0c-68538aeca03f@github.com>
Message-ID: <1qLvwj0st1yI2-ze4JF8uyzHB8VVuBHHgOym-WFFB28=.6d926e15-39ca-4491-b7b4-8d91ad32a61c@github.com>

On Wed, 9 Apr 2025 14:02:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more explanation
>
> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 73:
> 
>> 71:  * control path may eventually reach an invocation of an {@code Unsafe} method
>> 72:  * with illegal arguments, the symptoms of undefined behavior may be present
>> 73:  * even before the invocation of the {@code Unsafe} method.
> 
> I think you can talk in a more JIT-oriented manner, that while Unsafe is mostly set up to be the hooks between core libraries and hotspot runtime, hotspot compiler may interpret the input values and perform aggressive optimizations with contracts that cannot be explicitly expressed by Java program semantics.

Done, not only the JIT, but the runtime may exhibit unpredictable behaviors in the presence of UB, too.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2036533697

From qamai at openjdk.org  Thu Apr 10 05:33:39 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 10 Apr 2025 05:33:39 GMT
Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla
 Unsafe intrinsics [v2]
In-Reply-To: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
Message-ID: <i2ijFRN0BIccWnWwBAfiluAIPrIAMdolvcj_kwZ-QpI=.8a557e8c-600a-4812-87de-89d87ae1c40f@github.com>

> Hi,
> 
> This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`.
> 
> Please take a look and leave your suggestions, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  more explanation

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1425/files
  - new: https://git.openjdk.org/valhalla/pull/1425/files/ebfbd7b2..b869e10c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1425&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1425&range=00-01

  Stats: 22 lines in 1 file changed: 18 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1425.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1425/head:pull/1425

PR: https://git.openjdk.org/valhalla/pull/1425

From thartmann at openjdk.org  Thu Apr 10 06:01:59 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Apr 2025 06:01:59 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v5]
In-Reply-To: <t4yHvokFe2K0rRPIfbkCLS-PT_ugD4Rft-AYZ2EzwnE=.889d6569-5fa8-4cac-a329-f5ec3dd8e13f@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
 <t4yHvokFe2K0rRPIfbkCLS-PT_ugD4Rft-AYZ2EzwnE=.889d6569-5fa8-4cac-a329-f5ec3dd8e13f@github.com>
Message-ID: <kxWfi1pdKasUD2g7099jhXUol1gJTiSxbUvpEQTvFBI=.72c3eb5f-1116-4aa8-afdd-94d51b7a0335@github.com>

On Wed, 9 Apr 2025 12:52:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
>> 
>> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove obsolete annotation

Right, the `TestNullableInlineTypes.java` failure is a known issue.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1364#issuecomment-2791640401

From liach at openjdk.org  Thu Apr 10 06:02:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 06:02:00 GMT
Subject: [lworld] Integrated: 8348606: [lworld] Substitutability test may
 perform heap allocations
In-Reply-To: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
Message-ID: <Q-vzWgDIrGR214IsSInBdJEtRhodewzafZiNtlJ7ubk=.b0ef0be8-7958-4b54-b027-4a0e81775cec@github.com>

On Thu, 13 Feb 2025 00:10:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
> 
> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.

This pull request has now been integrated.

Changeset: 15a064c7
Author:    Chen Liang <liach at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/15a064c787fe5ef7972ad7d3de8f0c42b7a0a288
Stats:     298 lines in 6 files changed: 279 ins; 10 del; 9 mod

8348606: [lworld] Substitutability test may perform heap allocations

Co-authored-by: Tobias Hartmann <thartmann at openjdk.org>

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

PR: https://git.openjdk.org/valhalla/pull/1364

From chagedorn at openjdk.org  Thu Apr 10 06:16:20 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Apr 2025 06:16:20 GMT
Subject: [lworld] RFR: 8353717: [lworld] Complete merge of 8350756
Message-ID: <vytFX54840UOYEjsqhdi7x_EFTEXgLNbuR1Z-9WkXAE=.3b245081-a552-4781-a7ec-8fdace084c04@github.com>

This patch fixes some failures after merging JDK-25+14 in:

1. [JDK-8333393](https://bugs.openjdk.org/browse/JDK-8333393) improved the "split Phi through MergeMem" optimization and was merged in:
    1. This should fix [JDK-8327465](https://bugs.openjdk.org/browse/JDK-8327465) (it does not reproduce anymore but I think it's still an issue before this patch): When adding `Phi` nodes to the `OuterStripMinedLoop` node, it should match the number of `Phi` nodes at the `CountedLoop` node. However, during IGVN, we could split some phis of the `CountedLoop` node through `MergeMems` which created more phi nodes at the `OuterStripMinedLoop` node. But these phis could not be split further and we hit an assertion failure due to this phi number mismatch. Only with JDK-8333393, we can further split these phis at the `OuterStripMinedLoop` node and we no longer hit the assert. I've therefore closed JDK-8327465 as a dup.
    2. The merge of JDK-8333393 was not correct:
        1. We ended up splitting fewer phi nodes through mergemems as before and thus hitting case `1.` even more often.
        2. The Valhalla specific "Always split `Phi` when only having `MergeMem` inputs" optimization was broken. This leads to some IR rule failures since the splitting optimization is no longer performed which blocked some loop optimizations (e.g. turning a loop into a counted one and then apply more optimizations).
     
        I fixed both issues.
2. With JDK-25+14, some tests to check Loop Unswitching started to fail which matched on the number of `CountedLoop` nodes. The reason is that we can now eliminate one of the unswitched loop versions which we previously could not. Therefore, the number of `CountedLoop` nodes is one less. To fix that, I've changed the IR matching to `CCP1` where we still have both unswitched loop versions. This required the following:
    1. I had to adjust `INLINE_ARRAY_NULL_GUARD` to match on ideal graphs instead of the opto assembly. This can easily be done since all information is there in the ideal graph.
    2. I removed the `applyIf*` conditions for `UseG1GC` because we are not running any scenario with another GC.

Thanks,
Christian

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

Commit messages:
 - 8353717: [lworld] Complete merge of 8350756

Changes: https://git.openjdk.org/valhalla/pull/1426/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353717
  Stats: 37 lines in 7 files changed: 1 ins; 22 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1426.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1426/head:pull/1426

PR: https://git.openjdk.org/valhalla/pull/1426

From thartmann at openjdk.org  Thu Apr 10 06:55:41 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Apr 2025 06:55:41 GMT
Subject: [lworld] RFR: 8353717: [lworld] Complete merge of 8350756
In-Reply-To: <vytFX54840UOYEjsqhdi7x_EFTEXgLNbuR1Z-9WkXAE=.3b245081-a552-4781-a7ec-8fdace084c04@github.com>
References: <vytFX54840UOYEjsqhdi7x_EFTEXgLNbuR1Z-9WkXAE=.3b245081-a552-4781-a7ec-8fdace084c04@github.com>
Message-ID: <9l7vkvHP2GIBbRRFFziKKP8Z4Kz3BdvxGfaC2hKMsfU=.986e5f16-35df-4be5-8c22-4fd547e17a47@github.com>

On Thu, 10 Apr 2025 06:11:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes some failures after merging JDK-25+14 in:
> 
> 1. [JDK-8333393](https://bugs.openjdk.org/browse/JDK-8333393) improved the "split Phi through MergeMem" optimization and was merged in:
>     1. This should fix [JDK-8327465](https://bugs.openjdk.org/browse/JDK-8327465) (it does not reproduce anymore but I think it's still an issue before this patch): When adding `Phi` nodes to the `OuterStripMinedLoop` node, it should match the number of `Phi` nodes at the `CountedLoop` node. However, during IGVN, we could split some phis of the `CountedLoop` node through `MergeMems` which created more phi nodes at the `OuterStripMinedLoop` node. But these phis could not be split further and we hit an assertion failure due to this phi number mismatch. Only with JDK-8333393, we can further split these phis at the `OuterStripMinedLoop` node and we no longer hit the assert. I've therefore closed JDK-8327465 as a dup.
>     2. The merge of JDK-8333393 was not correct:
>         1. We ended up splitting fewer phi nodes through mergemems as before and thus hitting case `1.` even more often.
>         2. The Valhalla specific "Always split `Phi` when only having `MergeMem` inputs" optimization was broken. This leads to some IR rule failures since the splitting optimization is no longer performed which blocked some loop optimizations (e.g. turning a loop into a counted one and then apply more optimizations).
>      
>         I fixed both issues.
> 2. With JDK-25+14, some tests to check Loop Unswitching started to fail which matched on the number of `CountedLoop` nodes. The reason is that we can now eliminate one of the unswitched loop versions which we previously could not. Therefore, the number of `CountedLoop` nodes is one less. To fix that, I've changed the IR matching to `CCP1` where we still have both unswitched loop versions. This required the following:
>     1. I had to adjust `INLINE_ARRAY_NULL_GUARD` to match on ideal graphs instead of the opto assembly. This can easily be done since all information is there in the ideal graph.
>     2. I removed the `applyIf*` conditions for `UseG1GC` because we are not running any scenario with another GC.
> 
> Thanks,
> Christian

Looks good to me. Thanks for fixing this Christian!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1426#pullrequestreview-2755534874

From chagedorn at openjdk.org  Thu Apr 10 07:27:38 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Apr 2025 07:27:38 GMT
Subject: [lworld] RFR: 8353717: [lworld] Complete merge of 8350756
In-Reply-To: <vytFX54840UOYEjsqhdi7x_EFTEXgLNbuR1Z-9WkXAE=.3b245081-a552-4781-a7ec-8fdace084c04@github.com>
References: <vytFX54840UOYEjsqhdi7x_EFTEXgLNbuR1Z-9WkXAE=.3b245081-a552-4781-a7ec-8fdace084c04@github.com>
Message-ID: <LJfN12v3jB5yWH_O3x7vQPX5oBGg47MvyjpdM67Vihg=.beb805e0-da8f-4011-b0bb-5cd31bb33b13@github.com>

On Thu, 10 Apr 2025 06:11:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes some failures after merging JDK-25+14 in:
> 
> 1. [JDK-8333393](https://bugs.openjdk.org/browse/JDK-8333393) improved the "split Phi through MergeMem" optimization and was merged in:
>     1. This should fix [JDK-8327465](https://bugs.openjdk.org/browse/JDK-8327465) (it does not reproduce anymore but I think it's still an issue before this patch): When adding `Phi` nodes to the `OuterStripMinedLoop` node, it should match the number of `Phi` nodes at the `CountedLoop` node. However, during IGVN, we could split some phis of the `CountedLoop` node through `MergeMems` which created more phi nodes at the `OuterStripMinedLoop` node. But these phis could not be split further and we hit an assertion failure due to this phi number mismatch. Only with JDK-8333393, we can further split these phis at the `OuterStripMinedLoop` node and we no longer hit the assert. I've therefore closed JDK-8327465 as a dup.
>     2. The merge of JDK-8333393 was not correct:
>         1. We ended up splitting fewer phi nodes through mergemems as before and thus hitting case `1.` even more often.
>         2. The Valhalla specific "Always split `Phi` when only having `MergeMem` inputs" optimization was broken. This leads to some IR rule failures since the splitting optimization is no longer performed which blocked some loop optimizations (e.g. turning a loop into a counted one and then apply more optimizations).
>      
>         I fixed both issues.
> 2. With JDK-25+14, some tests to check Loop Unswitching started to fail which matched on the number of `CountedLoop` nodes. The reason is that we can now eliminate one of the unswitched loop versions which we previously could not. Therefore, the number of `CountedLoop` nodes is one less. To fix that, I've changed the IR matching to `CCP1` where we still have both unswitched loop versions. This required the following:
>     1. I had to adjust `INLINE_ARRAY_NULL_GUARD` to match on ideal graphs instead of the opto assembly. This can easily be done since all information is there in the ideal graph.
>     2. I removed the `applyIf*` conditions for `UseG1GC` because we are not running any scenario with another GC.
> 
> Thanks,
> Christian

Thanks for the review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1426#issuecomment-2791802452

From chagedorn at openjdk.org  Thu Apr 10 07:27:38 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Apr 2025 07:27:38 GMT
Subject: [lworld] Integrated: 8353717: [lworld] Complete merge of 8350756
In-Reply-To: <vytFX54840UOYEjsqhdi7x_EFTEXgLNbuR1Z-9WkXAE=.3b245081-a552-4781-a7ec-8fdace084c04@github.com>
References: <vytFX54840UOYEjsqhdi7x_EFTEXgLNbuR1Z-9WkXAE=.3b245081-a552-4781-a7ec-8fdace084c04@github.com>
Message-ID: <6FYzxaaMK1uwYheQt041Pgj97z1-Jm4uxP3UF_KjaVc=.b02726ca-8bb8-45de-b70a-61ff8b311477@github.com>

On Thu, 10 Apr 2025 06:11:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes some failures after merging JDK-25+14 in:
> 
> 1. [JDK-8333393](https://bugs.openjdk.org/browse/JDK-8333393) improved the "split Phi through MergeMem" optimization and was merged in:
>     1. This should fix [JDK-8327465](https://bugs.openjdk.org/browse/JDK-8327465) (it does not reproduce anymore but I think it's still an issue before this patch): When adding `Phi` nodes to the `OuterStripMinedLoop` node, it should match the number of `Phi` nodes at the `CountedLoop` node. However, during IGVN, we could split some phis of the `CountedLoop` node through `MergeMems` which created more phi nodes at the `OuterStripMinedLoop` node. But these phis could not be split further and we hit an assertion failure due to this phi number mismatch. Only with JDK-8333393, we can further split these phis at the `OuterStripMinedLoop` node and we no longer hit the assert. I've therefore closed JDK-8327465 as a dup.
>     2. The merge of JDK-8333393 was not correct:
>         1. We ended up splitting fewer phi nodes through mergemems as before and thus hitting case `1.` even more often.
>         2. The Valhalla specific "Always split `Phi` when only having `MergeMem` inputs" optimization was broken. This leads to some IR rule failures since the splitting optimization is no longer performed which blocked some loop optimizations (e.g. turning a loop into a counted one and then apply more optimizations).
>      
>         I fixed both issues.
> 2. With JDK-25+14, some tests to check Loop Unswitching started to fail which matched on the number of `CountedLoop` nodes. The reason is that we can now eliminate one of the unswitched loop versions which we previously could not. Therefore, the number of `CountedLoop` nodes is one less. To fix that, I've changed the IR matching to `CCP1` where we still have both unswitched loop versions. This required the following:
>     1. I had to adjust `INLINE_ARRAY_NULL_GUARD` to match on ideal graphs instead of the opto assembly. This can easily be done since all information is there in the ideal graph.
>     2. I removed the `applyIf*` conditions for `UseG1GC` because we are not running any scenario with another GC.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 603ac0e3
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/603ac0e3eb70222a4ac8bb60f840c83ad82b5d89
Stats:     37 lines in 7 files changed: 1 ins; 22 del; 14 mod

8353717: [lworld] Complete merge of 8350756

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1426

From rriggs at openjdk.org  Thu Apr 10 13:32:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Apr 2025 13:32:46 GMT
Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla
 Unsafe intrinsics [v2]
In-Reply-To: <i2ijFRN0BIccWnWwBAfiluAIPrIAMdolvcj_kwZ-QpI=.8a557e8c-600a-4812-87de-89d87ae1c40f@github.com>
References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
 <i2ijFRN0BIccWnWwBAfiluAIPrIAMdolvcj_kwZ-QpI=.8a557e8c-600a-4812-87de-89d87ae1c40f@github.com>
Message-ID: <jrnugGKDv_YiqkKzGgTItgM2Xvy364tPBGbmupwTt1w=.b4237d17-b432-4383-a5c8-6628ab38a2d0@github.com>

On Thu, 10 Apr 2025 05:33:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`.
>> 
>> Please take a look and leave your suggestions, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more explanation

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 94:

> 92:  * <p>
> 93:  * By default, usage of all methods in this class exhibits undefined behavior,
> 94:  * unless otherwise explicitly specified.

The "by default" and "unless otherwise specified" seems to be redundant.

Suggestion:

 * Unless otherwise explicitly specified, all methods in this class can exhibit undefined behavior.
 * .

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 442:

> 440:      * effectively final as well as definitely assigned to with the return
> 441:      * value of this method. The object must also be not assigned to another
> 442:      * local variable.

Why this restriction? What assumption is violated if there is a second assignment?

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 447:

> 445:      * other usage, such as loading from or returning it, is illegal. The only
> 446:      * exception is the implicit check cast inserted by the compiler on the
> 447:      * return value of this method. Explicit check casts are not allowed.

"not allowed"?  But there is no enforcement; unpredictable behavior yes.

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 449:

> 447:      * return value of this method. Explicit check casts are not allowed.
> 448:      * </ul>
> 449:      * Illegal usage of this method exhibits undefined behavior even if the

may or can; but not always.

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 470:

> 468:      * <li>After the invocation of this method, the variable that holds the
> 469:      * argument passed into this method must not be used.
> 470:      * </ul>

I would add the exhortation that every field of the value object must have a value.

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 472:

> 470:      * </ul>
> 471:      * Illegal usage of this method exhibits undefined behavior even if the
> 472:      * illegal statements are never actually reached at runtime.

Another can/may exhibit case; improve the phrase everywhere.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037359302
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037392238
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037395701
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037398261
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037405322
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037402279

From livedinsquares at gmail.com  Thu Apr 10 13:53:07 2025
From: livedinsquares at gmail.com (Jonathan F)
Date: Thu, 10 Apr 2025 06:53:07 -0700
Subject: Nullability syntax
Message-ID: <CABR7qmdzVyPsMrt-GUTL+s_qT=hy05FVjR0WtBVH6U6+qby8LQ@mail.gmail.com>

 It seems the syntax of nullable types is extra-important for its
usability, so here?s an idea which perhaps the EG hasn?t considered. Remi
has mentioned a 2-states model? - maybe this is different:

- Assume there?s some way (any way) to specify default nullability within
some scope: to set either that String means String!, or that it means
String?. If you don?t specify anything, as now, String means unspecified
null.

- Then: if you set default nullability to ! , you?re allowed to write
String or String? but not String! (i.e. you can?t belabour the
non-nullability of a particular String)

- Likewise if you set default nullability to ? , you?re allowed to write
String or String! but not String?. Or maybe we don?t even need this default.

- (I think?) if you don?t set a default so it's 'unspecified null? (as
now), then neither String? nor String! is allowed: they force you to set a
default.


The point of this is:

- There?s clarity in only being allowed to use 1 type of punctuation in a
class. And seeing it tells you there?s a default.

- If you see ? or ! in a sample of code you?ll know what a bare String
means: ?the opposite'.

- Pasting raw code between two classes with different nullability will
often give compile errors from mixed punctuation (unless your IDE adjusts
the code, which hopefully IDEs will).

- This fits with simple ways to convert an existing class to being
null-aware: set the default to !, so existing types are reinterpreted as
null-restricted, then fix errors by adding ? piecemeal. But if you want to
make minimal changes you may want to set the default to ? instead, then add
! piecemeal; or again maybe we don?t need that default - even simpler.

As for actually using ?unspecified null? (which I hope will be rare in
null-aware code) - maybe String* or even String!? is OK.

I hope that (or something like it) makes sense.

Jonathan

Jonathan Finn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250410/d7dc4fa2/attachment-0001.htm>

From qamai at openjdk.org  Thu Apr 10 15:29:40 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 10 Apr 2025 15:29:40 GMT
Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla
 Unsafe intrinsics [v3]
In-Reply-To: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
Message-ID: <RKlgBmwJEv8WzLHN4ymGZs0o_-CsJG0Tngm8WDN6e6Q=.a66c0aba-2ea2-428c-bdb0-7989a6799bb2@github.com>

> Hi,
> 
> This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`.
> 
> Please take a look and leave your suggestions, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  remove unnecessary statements

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1425/files
  - new: https://git.openjdk.org/valhalla/pull/1425/files/b869e10c..130f897f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1425&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1425&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1425.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1425/head:pull/1425

PR: https://git.openjdk.org/valhalla/pull/1425

From qamai at openjdk.org  Thu Apr 10 15:29:40 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 10 Apr 2025 15:29:40 GMT
Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla
 Unsafe intrinsics [v2]
In-Reply-To: <jrnugGKDv_YiqkKzGgTItgM2Xvy364tPBGbmupwTt1w=.b4237d17-b432-4383-a5c8-6628ab38a2d0@github.com>
References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
 <i2ijFRN0BIccWnWwBAfiluAIPrIAMdolvcj_kwZ-QpI=.8a557e8c-600a-4812-87de-89d87ae1c40f@github.com>
 <jrnugGKDv_YiqkKzGgTItgM2Xvy364tPBGbmupwTt1w=.b4237d17-b432-4383-a5c8-6628ab38a2d0@github.com>
Message-ID: <m_0YtGAOE8FNdf3Nt0knEpAzLEm9B63TfCxff0bBOSA=.568bfe6b-a65e-4af5-9fbf-175c7066821b@github.com>

On Thu, 10 Apr 2025 13:15:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more explanation
>
> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 94:
> 
>> 92:  * <p>
>> 93:  * By default, usage of all methods in this class exhibits undefined behavior,
>> 94:  * unless otherwise explicitly specified.
> 
> The "by default" and "unless otherwise specified" seems to be redundant.
> 
> Suggestion:
> 
>  * Unless otherwise explicitly specified, all methods in this class can exhibit undefined behavior.
>  * .

I decide to just remove it as each method specifies its behaviours already.

> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 442:
> 
>> 440:      * effectively final as well as definitely assigned to with the return
>> 441:      * value of this method. The object must also be not assigned to another
>> 442:      * local variable.
> 
> Why this restriction? What assumption is violated if there is a second assignment?

There is none, but it would be easier to specify the restriction on `Unsafe::finishPrivateBuffer` as the only variable referring to the larval object is the one passed into that method. Otherwise, we must say that all variables referring to the object must not be used. This, however, sounds like a runtime constraint while what we really mean is a compile-time constraint. As a result, I think this restriction is harmless but make our life easier.

> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 447:
> 
>> 445:      * other usage, such as loading from or returning it, is illegal. The only
>> 446:      * exception is the implicit check cast inserted by the compiler on the
>> 447:      * return value of this method. Explicit check casts are not allowed.
> 
> "not allowed"?  But there is no enforcement; unpredictable behavior yes.

Not allowed here in the sense that failure to do so will result in undefined behavior.

> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 449:
> 
>> 447:      * return value of this method. Explicit check casts are not allowed.
>> 448:      * </ul>
>> 449:      * Illegal usage of this method exhibits undefined behavior even if the
> 
> may or can; but not always.

Illegal usage ALWAYS exhibits undefined behavior, the uncertainty here is that whether this undefined behavior manifests itself as an unexpected operation.

> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 470:
> 
>> 468:      * <li>After the invocation of this method, the variable that holds the
>> 469:      * argument passed into this method must not be used.
>> 470:      * </ul>
> 
> I would add the exhortation that every field of the value object must have a value.

`Unsafe::makePrivateBuffer` takes a non-larval value object so all of its fields always have a value.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037672390
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037678291
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037679325
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037681806
PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2037683401

From fparain at openjdk.org  Thu Apr 10 16:02:52 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 10 Apr 2025 16:02:52 GMT
Subject: [lworld] RFR: 8341761: Update JNI methods to support new field and
 array layouts
Message-ID: <87ZpsJN-S2bQ2Qm-Px7wfDhspKpYuKQSwtVhgmq6qHI=.dee87895-6b0d-4103-a5eb-4e4d4f7b8dcb@github.com>

Update JNI methods to support new field and array layouts.
Extend testing of JNI methods

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

Commit messages:
 - Update JNI methods to support new layouts

Changes: https://git.openjdk.org/valhalla/pull/1427/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1427&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341761
  Stats: 362 lines in 3 files changed: 340 ins; 14 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1427.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1427/head:pull/1427

PR: https://git.openjdk.org/valhalla/pull/1427

From archie.cobbs at gmail.com  Thu Apr 10 22:23:51 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 10 Apr 2025 17:23:51 -0500
Subject: Nullability syntax
In-Reply-To: <CABR7qmdzVyPsMrt-GUTL+s_qT=hy05FVjR0WtBVH6U6+qby8LQ@mail.gmail.com>
References: <CABR7qmdzVyPsMrt-GUTL+s_qT=hy05FVjR0WtBVH6U6+qby8LQ@mail.gmail.com>
Message-ID: <CANSoFxtPJEUyrunLromfECQB2h6g1gdNCvhFwK9b-PYLKXQwqA@mail.gmail.com>

My opinion only of course, but I think this would be a step backwards.

You would be adding an extra level of mental redirection that a developer
would have to go through every time they see "String".

Now sometimes the cost of a level of indirection is worthwhile .. for
example, using "import java.util.List" means in exchange for that extra
level of redirection, we can say "List" instead of "java.util.List". So
import statements are a worthwhile trade-off. Helping the cause, it's rare
that I would ever declare a class named "List" in the unnamed package, and
I haven't used AWT in 20 years, so these days when I see "List" there's not
much ambiguity.

But "String" is used everywhere. And yet we are only talking about saving a
single character (what I love about the nullity syntax idea is that in a
single character, so much information that I need constantly, all over the
place, is being conveyed). So the trade-off doesn't seem worth it.

There?s clarity in only being allowed to use 1 type of punctuation in a
> class.


Hmm, I actually feel the opposite. Most code is write once, read many, so
you want to optimize for the reading of it, not the writing of it.

-Archie

On Thu, Apr 10, 2025 at 8:54?AM Jonathan F <livedinsquares at gmail.com> wrote:

> It seems the syntax of nullable types is extra-important for its
> usability, so here?s an idea which perhaps the EG hasn?t considered. Remi
> has mentioned a 2-states model? - maybe this is different:
>
> - Assume there?s some way (any way) to specify default nullability within
> some scope: to set either that String means String!, or that it means
> String?. If you don?t specify anything, as now, String means unspecified
> null.
>
> - Then: if you set default nullability to ! , you?re allowed to write
> String or String? but not String! (i.e. you can?t belabour the
> non-nullability of a particular String)
>
> - Likewise if you set default nullability to ? , you?re allowed to write
> String or String! but not String?. Or maybe we don?t even need this default.
>
> - (I think?) if you don?t set a default so it's 'unspecified null? (as
> now), then neither String? nor String! is allowed: they force you to set a
> default.
>
>
> The point of this is:
>
> - There?s clarity in only being allowed to use 1 type of punctuation in a
> class. And seeing it tells you there?s a default.
>
> - If you see ? or ! in a sample of code you?ll know what a bare String
> means: ?the opposite'.
>
> - Pasting raw code between two classes with different nullability will
> often give compile errors from mixed punctuation (unless your IDE adjusts
> the code, which hopefully IDEs will).
>
> - This fits with simple ways to convert an existing class to being
> null-aware: set the default to !, so existing types are reinterpreted as
> null-restricted, then fix errors by adding ? piecemeal. But if you want to
> make minimal changes you may want to set the default to ? instead, then add
> ! piecemeal; or again maybe we don?t need that default - even simpler.
>
> As for actually using ?unspecified null? (which I hope will be rare in
> null-aware code) - maybe String* or even String!? is OK.
>
> I hope that (or something like it) makes sense.
>
> Jonathan
>
> Jonathan Finn
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250410/223c6889/attachment-0001.htm>

From brian.goetz at oracle.com  Thu Apr 10 22:56:30 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 10 Apr 2025 22:56:30 +0000
Subject: Nullability syntax
In-Reply-To: <CABR7qmdzVyPsMrt-GUTL+s_qT=hy05FVjR0WtBVH6U6+qby8LQ@mail.gmail.com>
References: <CABR7qmdzVyPsMrt-GUTL+s_qT=hy05FVjR0WtBVH6U6+qby8LQ@mail.gmail.com>
Message-ID: <36ECB5FD-61E6-4C03-8A80-7C9FFB86F973@oracle.com>

Yes, this is something we have considered in quite some depth. Sometimes people refer to this as ?The flippening?.
The benefit of such a scheme is that null restricted is a better default, and the annotation burden of annotating a code base, old or new, much much lower. This is not small.  But the downside is immense.

The downside is that it would be an incompatibility that is orders of magnitude bigger than anything we?ve contemplated before.  What it would do is fork the language in two, which violates a key Java principle: ?one language with the same meaning everywhere.?  The same goes with all the different flavors of this proposal - ?new class?, @LanguageLevel, etc.  They share the same characteristic that they want to retroactively redefine the meaning of existing Java source code.

People like to think this is a clever hack, but in reality would be the biggest philosophical change we?ve ever made.  It?s not something we would consider lightly ? and not something we will consider at all until after the current round of Valhalla JEPS are completed.

Sent from my iPad

On Apr 10, 2025, at 9:53?AM, Jonathan F <livedinsquares at gmail.com> wrote:

?
It seems the syntax of nullable types is extra-important for its usability, so here?s an idea which perhaps the EG hasn?t considered. Remi has mentioned a 2-states model? - maybe this is different:

- Assume there?s some way (any way) to specify default nullability within some scope: to set either that String means String!, or that it means String?. If you don?t specify anything, as now, String means unspecified null.

- Then: if you set default nullability to ! , you?re allowed to write String or String? but not String! (i.e. you can?t belabour the non-nullability of a particular String)

- Likewise if you set default nullability to ? , you?re allowed to write String or String! but not String?. Or maybe we don?t even need this default.

- (I think?) if you don?t set a default so it's 'unspecified null? (as now), then neither String? nor String! is allowed: they force you to set a default.


The point of this is:

- There?s clarity in only being allowed to use 1 type of punctuation in a class. And seeing it tells you there?s a default.

- If you see ? or ! in a sample of code you?ll know what a bare String means: ?the opposite'.

- Pasting raw code between two classes with different nullability will often give compile errors from mixed punctuation (unless your IDE adjusts the code, which hopefully IDEs will).

- This fits with simple ways to convert an existing class to being null-aware: set the default to !, so existing types are reinterpreted as null-restricted, then fix errors by adding ? piecemeal. But if you want to make minimal changes you may want to set the default to ? instead, then add ! piecemeal; or again maybe we don?t need that default - even simpler.

As for actually using ?unspecified null? (which I hope will be rare in null-aware code) - maybe String* or even String!? is OK.

I hope that (or something like it) makes sense.

Jonathan

Jonathan Finn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250410/b69f43df/attachment.htm>

From fparain at openjdk.org  Fri Apr 11 12:25:00 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 11 Apr 2025 12:25:00 GMT
Subject: [lworld] Integrated: 8341761: Update JNI methods to support new field
 and array layouts
In-Reply-To: <87ZpsJN-S2bQ2Qm-Px7wfDhspKpYuKQSwtVhgmq6qHI=.dee87895-6b0d-4103-a5eb-4e4d4f7b8dcb@github.com>
References: <87ZpsJN-S2bQ2Qm-Px7wfDhspKpYuKQSwtVhgmq6qHI=.dee87895-6b0d-4103-a5eb-4e4d4f7b8dcb@github.com>
Message-ID: <MLvZLwqukf6EkE4CTsgdlbwfESg1AP2gk1nt8HBOgDM=.bee77c51-1653-4247-becd-cbf1b0f325b3@github.com>

On Thu, 10 Apr 2025 15:57:25 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Update JNI methods to support new field and array layouts.
> Extend testing of JNI methods

This pull request has now been integrated.

Changeset: 0e899b25
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0e899b25e5e2b60989122495f38987bb5d236ba1
Stats:     362 lines in 3 files changed: 340 ins; 14 del; 8 mod

8341761: Update JNI methods to support new field and array layouts

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

PR: https://git.openjdk.org/valhalla/pull/1427

From dsimms at openjdk.org  Mon Apr 14 13:12:59 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Apr 2025 13:12:59 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <tayWOA6Lfk6xdJbJncF-ObNhyJcePiuk7726p3vmny0=.983a373a-be6e-438d-b230-1d784d0c8ca9@github.com>

Merge tag 'jdk-25+17' into lworld_merge_jdk_25_17
Added tag jdk-25+17 for changeset bd749221

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

Commit messages:
 - Adjust include ordering
 - Merge tag 'jdk-25+17' into lworld_merge_jdk_25_17
 - 8338675: javac shouldn't silently change .jar files on the classpath
 - 8353058: [PPC64] Some IR framework tests are failing after JDK-8352595
 - 8353325: Rewrite appcds/methodHandles test cases to use CDSAppTester
 - 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable
 - 8352645: Add tool support to check order of includes
 - 8353479: jcmd with streaming output breaks intendation
 - 8353217: Build libsleef on macos-aarch64
 - 8353234: Refactor XMLSecurityPropertyManager
 - ... and 102 more: https://git.openjdk.org/valhalla/compare/0f63f742...d0e4eb03

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

Changes: https://git.openjdk.org/valhalla/pull/1431/files
  Stats: 23014 lines in 675 files changed: 13218 ins; 8003 del; 1793 mod
  Patch: https://git.openjdk.org/valhalla/pull/1431.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1431/head:pull/1431

PR: https://git.openjdk.org/valhalla/pull/1431

From dsimms at openjdk.org  Mon Apr 14 13:15:25 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Apr 2025 13:15:25 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <5p8iK5VrMdX6y5r6a8JVrX8mrmMtdMdE26PUpT-rOHo=.d1c95123-e7c1-4075-94d1-34f35e8e400c@github.com>
References: <5p8iK5VrMdX6y5r6a8JVrX8mrmMtdMdE26PUpT-rOHo=.d1c95123-e7c1-4075-94d1-34f35e8e400c@github.com>
Message-ID: <lPqbD2sCP-a-r-vAXplzZi8-rr0ACW8f3iwf7dmM5JI=.bccb4328-fb1a-4dee-8362-200cff5d428f@github.com>

On Mon, 14 Apr 2025 08:08:47 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+16
> 
> Incremental merge, discovered JDK-8343233 removed field sorting in depot and ciInstanceKlass, stuble changes caused many failures

This pull request has now been integrated.

Changeset: 0f63f742
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0f63f74263eebb5aa19913506a12b2a51fc26fa3
Stats:     53021 lines in 1637 files changed: 12731 ins; 34075 del; 6215 mod

Merge jdk

Merge jdk-25+16

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

PR: https://git.openjdk.org/valhalla/pull/1429

From dsimms at openjdk.org  Mon Apr 14 13:15:23 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Apr 2025 13:15:23 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <5p8iK5VrMdX6y5r6a8JVrX8mrmMtdMdE26PUpT-rOHo=.d1c95123-e7c1-4075-94d1-34f35e8e400c@github.com>

Merge jdk-25+16

Incremental merge, discovered JDK-8343233 removed field sorting in depot and ciInstanceKlass, stuble changes caused many failures

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

Commit messages:
 - Adjust testing 8354366, 8354404, 8354408 8354283
 - Merge jdk-25+16
 - 8352579: Refactor CDS legacy optimization for lambda proxy classes
 - 8334322: Misleading values of keys in jpackage resource bundle
 - 8352812: remove useless class and function parameter in SuspendThread impl
 - 8352948: Remove leftover runtime_x86_32.cpp after 32-bit x86 removal
 - 8348400: GenShen: assert(ShenandoahHeap::heap()->is_full_gc_in_progress() || (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity #
 - 8348907: Stress times out when is executed with ZGC
 - 8352766: Problemlist hotspot tier1 tests requiring tools that are not included in static JDK
 - 8352716: (tz) Update Timezone Data to 2025b
 - ... and 100 more: https://git.openjdk.org/valhalla/compare/603ac0e3...0259c3f4

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

Changes: https://git.openjdk.org/valhalla/pull/1429/files
  Stats: 53021 lines in 1637 files changed: 12731 ins; 34075 del; 6215 mod
  Patch: https://git.openjdk.org/valhalla/pull/1429.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1429/head:pull/1429

PR: https://git.openjdk.org/valhalla/pull/1429

From dsimms at openjdk.org  Tue Apr 15 07:54:21 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Apr 2025 07:54:21 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <tayWOA6Lfk6xdJbJncF-ObNhyJcePiuk7726p3vmny0=.983a373a-be6e-438d-b230-1d784d0c8ca9@github.com>
References: <tayWOA6Lfk6xdJbJncF-ObNhyJcePiuk7726p3vmny0=.983a373a-be6e-438d-b230-1d784d0c8ca9@github.com>
Message-ID: <1wdvsgWSIRkMaQeqYTgCV2eSjVyS5cTOF9lICINszIQ=.7087e71d-30c9-409c-875b-2d8b362fe301@github.com>

On Mon, 14 Apr 2025 09:35:00 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+17' into lworld_merge_jdk_25_17
> Added tag jdk-25+17 for changeset bd749221

This pull request has now been integrated.

Changeset: 2de31644
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2de31644cde0d07e67913dc5b94ba6f3efca1da2
Stats:     23014 lines in 675 files changed: 13218 ins; 8003 del; 1793 mod

Merge jdk

Merge jdk-25+17

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

PR: https://git.openjdk.org/valhalla/pull/1431

From liach at openjdk.org  Tue Apr 15 23:46:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Apr 2025 23:46:11 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest
Message-ID: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>

The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.

Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)

Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.

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

Commit messages:
 - 8354728: [lworld] Langtools work to update strict implementation to latest

Changes: https://git.openjdk.org/valhalla/pull/1432/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1432&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354728
  Stats: 559 lines in 15 files changed: 252 ins; 91 del; 216 mod
  Patch: https://git.openjdk.org/valhalla/pull/1432.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1432/head:pull/1432

PR: https://git.openjdk.org/valhalla/pull/1432

From vromero at openjdk.org  Wed Apr 16 00:51:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Apr 2025 00:51:56 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest
In-Reply-To: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
Message-ID: <gUHN-d4cEQFXKZGrrxdSWfu68orpVuJqtL3FkJLJtWE=.cc81d4b0-2cb2-4e9d-9cc8-c24b3303bc81@github.com>

On Tue, 15 Apr 2025 23:35:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
> 
> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
> 
> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 391:

> 389:         @Override
> 390:         public String toString() {
> 391:             return "STRICT";

so we want the `toString` result to be `STRICT_INIT`?

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 64:

> 62:                     SAME_LOCALS_1_STACK_ITEM_EXTENDED = 247,
> 63:                     SAME_EXTENDED = 251;
> 64:     private static final int BASE_FRAMES_UPPER_LIMIT = SAME_LOCALS_1_STACK_ITEM_EXTENDED; // not inclusive

shouldn't this be EARLY_LARVAL now?

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java line 1364:

> 1362: 
> 1363:         Set<VarSymbol> unsetFieldsAtPC = cpToUnsetFieldsMap.get(pc);
> 1364:         boolean generateAssertUnsetFieldsEntry = unsetFieldsAtPC != null && generateEarlyLarvalFrame && hasUninitalizedThis

we should probably rename this variable

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045790139
PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045791461
PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045780965

From vromero at openjdk.org  Wed Apr 16 01:43:01 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Apr 2025 01:43:01 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest
In-Reply-To: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
Message-ID: <irWdncRHOvGalt8O3F1Lg1LOD0K0q_giMuZh0h0Xihw=.03ef1a3b-2a89-423d-96af-8cfc97f5bbdf@github.com>

On Tue, 15 Apr 2025 23:35:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
> 
> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
> 
> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.

src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 301:

> 299:                         continue;
> 300:                     }
> 301:                     case 247 -> {

side: in some classes we use constants for the frame types here we are using literals, we probably should use the same approach always, this is not related to the PR but could be fixed in a separate issue

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 178:

> 176:         if (offsetDelta < 0) throw new IllegalArgumentException("Invalid stack map frames order");
> 177:         // enclosing frames
> 178:         writeLarvalFrame:

not a big fan of using labels, I wonder if the code can be refactored to avoid using them

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 299:

> 297:                 }
> 298:             }
> 299:             if (actualFrameType != 247 && !unsetFields.isEmpty() && !locals.contains(SimpleVerificationTypeInfo.UNINITIALIZED_THIS)) {

we should use a constant not a literal, 247, here

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045794207
PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045825185
PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045823752

From liach at openjdk.org  Wed Apr 16 02:03:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 02:03:59 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest
In-Reply-To: <irWdncRHOvGalt8O3F1Lg1LOD0K0q_giMuZh0h0Xihw=.03ef1a3b-2a89-423d-96af-8cfc97f5bbdf@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <irWdncRHOvGalt8O3F1Lg1LOD0K0q_giMuZh0h0Xihw=.03ef1a3b-2a89-423d-96af-8cfc97f5bbdf@github.com>
Message-ID: <FfsKKpNaQDTDwLCBIh4JEy9CunllbD-fTpIZ5JWM-sQ=.01329f34-a97a-4225-ae19-631f63227289@github.com>

On Wed, 16 Apr 2025 01:27:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 299:
> 
>> 297:                 }
>> 298:             }
>> 299:             if (actualFrameType != 247 && !unsetFields.isEmpty() && !locals.contains(SimpleVerificationTypeInfo.UNINITIALIZED_THIS)) {
> 
> we should use a constant not a literal, 247, here

Very true, this literal is also wrong

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045861478

From liach at openjdk.org  Wed Apr 16 02:27:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 02:27:53 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest
In-Reply-To: <gUHN-d4cEQFXKZGrrxdSWfu68orpVuJqtL3FkJLJtWE=.cc81d4b0-2cb2-4e9d-9cc8-c24b3303bc81@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <gUHN-d4cEQFXKZGrrxdSWfu68orpVuJqtL3FkJLJtWE=.cc81d4b0-2cb2-4e9d-9cc8-c24b3303bc81@github.com>
Message-ID: <Z5gk-zg_2gqmQCbbyeWfsS4HrnDma0TEH8JVPdezBK4=.13ea4080-92b3-4aed-a80b-05996cca867e@github.com>

On Wed, 16 Apr 2025 00:48:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 64:
> 
>> 62:                     SAME_LOCALS_1_STACK_ITEM_EXTENDED = 247,
>> 63:                     SAME_EXTENDED = 251;
>> 64:     private static final int BASE_FRAMES_UPPER_LIMIT = SAME_LOCALS_1_STACK_ITEM_EXTENDED; // not inclusive
> 
> shouldn't this be EARLY_LARVAL now?

Oh, I moved enclosing frames to another system, so this now intentionally rejects early larval.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045887256

From liach at openjdk.org  Wed Apr 16 02:44:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 02:44:01 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest
In-Reply-To: <gUHN-d4cEQFXKZGrrxdSWfu68orpVuJqtL3FkJLJtWE=.cc81d4b0-2cb2-4e9d-9cc8-c24b3303bc81@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <gUHN-d4cEQFXKZGrrxdSWfu68orpVuJqtL3FkJLJtWE=.cc81d4b0-2cb2-4e9d-9cc8-c24b3303bc81@github.com>
Message-ID: <rep_5POkNBphw2M2sqc1AHWdQR7LkZ75DCC4WoPlcOw=.f51b5675-ac9b-4ecb-b78d-6a512e9ffa6c@github.com>

On Wed, 16 Apr 2025 00:46:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 391:
> 
>> 389:         @Override
>> 390:         public String toString() {
>> 391:             return "STRICT";
> 
> so we want the `toString` result to be `STRICT_INIT`?

Yes, the new spec renamed the flag to `ACC_STRICT_INIT`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2045899212

From fparain at openjdk.org  Wed Apr 16 14:08:31 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 16 Apr 2025 14:08:31 GMT
Subject: [lworld] RFR: 8354852: [lworld] invalid interval when copying elements
 in arraycopy
Message-ID: <qKbYDBCEE9Og_58PrGmwZ6ocSDt85v5YTRJfDbViSNg=.4535784e-b5c1-45b8-b88a-79f5a1581dd3@github.com>

Fixing computation of the interval of values to be copied when array copying is applied to flat arrays.

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

Commit messages:
 - Fix copying interval and test for arraycopy on flat arrays

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

PR: https://git.openjdk.org/valhalla/pull/1433

From liach at openjdk.org  Wed Apr 16 15:42:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 15:42:52 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v2]
In-Reply-To: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
Message-ID: <Krs9AIQXvQwklccEHwy6AW12yuLEjSBLfq4ndTiBvuo=.0f17dc4f-3fa8-4d04-be6e-3f4e7dbfce77@github.com>

> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
> 
> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
> 
> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions, also rollback the getEntryType rename in javac, test updates

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1432/files
  - new: https://git.openjdk.org/valhalla/pull/1432/files/6643f1b4..52d38be4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1432&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1432&range=00-01

  Stats: 89 lines in 7 files changed: 43 ins; 14 del; 32 mod
  Patch: https://git.openjdk.org/valhalla/pull/1432.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1432/head:pull/1432

PR: https://git.openjdk.org/valhalla/pull/1432

From liach at openjdk.org  Wed Apr 16 15:42:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 15:42:54 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v2]
In-Reply-To: <irWdncRHOvGalt8O3F1Lg1LOD0K0q_giMuZh0h0Xihw=.03ef1a3b-2a89-423d-96af-8cfc97f5bbdf@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <irWdncRHOvGalt8O3F1Lg1LOD0K0q_giMuZh0h0Xihw=.03ef1a3b-2a89-423d-96af-8cfc97f5bbdf@github.com>
Message-ID: <BpscsziWwGA3JV_mMJdlpna1x5JPIyUqTcz7Ge5GmZs=.16b12346-8edd-4c65-8a1a-bce22ae9d16c@github.com>

On Wed, 16 Apr 2025 00:52:21 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestions, also rollback the getEntryType rename in javac, test updates
>
> src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 301:
> 
>> 299:                         continue;
>> 300:                     }
>> 301:                     case 247 -> {
> 
> side: in some classes we use constants for the frame types here we are using literals, we probably should use the same approach always, this is not related to the PR but could be fixed in a separate issue

Created https://bugs.openjdk.org/browse/JDK-8354871 to track this RFE.

> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 178:
> 
>> 176:         if (offsetDelta < 0) throw new IllegalArgumentException("Invalid stack map frames order");
>> 177:         // enclosing frames
>> 178:         writeLarvalFrame:
> 
> not a big fan of using labels, I wonder if the code can be refactored to avoid using them

Yep, factored these out to methods with extra asserts, does look cleaner

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2047206880
PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2047207557

From liach at openjdk.org  Wed Apr 16 15:45:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 15:45:09 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v2]
In-Reply-To: <gUHN-d4cEQFXKZGrrxdSWfu68orpVuJqtL3FkJLJtWE=.cc81d4b0-2cb2-4e9d-9cc8-c24b3303bc81@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <gUHN-d4cEQFXKZGrrxdSWfu68orpVuJqtL3FkJLJtWE=.cc81d4b0-2cb2-4e9d-9cc8-c24b3303bc81@github.com>
Message-ID: <wjUZ9OlRyrw4IJRJEFgXsT7kfAjWrewvra2Xs5r7v-g=.06d489fd-4782-4aa3-89f2-532f29029570@github.com>

On Wed, 16 Apr 2025 00:38:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestions, also rollback the getEntryType rename in javac, test updates
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java line 1364:
> 
>> 1362: 
>> 1363:         Set<VarSymbol> unsetFieldsAtPC = cpToUnsetFieldsMap.get(pc);
>> 1364:         boolean generateAssertUnsetFieldsEntry = unsetFieldsAtPC != null && generateEarlyLarvalFrame && hasUninitalizedThis
> 
> we should probably rename this variable

Done, now called `encloseWithEarlyLarvalFrame`

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2047218967

From rriggs at openjdk.org  Wed Apr 16 16:51:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Apr 2025 16:51:40 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v7]
In-Reply-To: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
Message-ID: <SQdKWdMn8FB-qUvkPJwvfHZTOaaEdemn84WHVC7-Hcs=.2639fb7c-94ad-492f-b5bf-85861eba9c0d@github.com>

> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
> Simplified WeakHashMap javadoc updates for IdentityException. 
> Added note to System.identityHashCode to include value objects.
> Added to class javadoc for IdentityHashMap for value objects.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge branch 'lworld' into 8346307-throws-identityexception
 - Merge branch 'lworld' into 8346307-throws-identityexception
 - Merge branch 'lworld' into 8346307-throws-identityexception
 - Merge
 - Expand javadoc reference to Reference
 - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception
 - Merge branch 'openjdk:lworld' into 8346307-throws-identityexception
 - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException
   Add APINote  and javadoc for IdentityException where it will be useful to know.
   Simplified WeakHashMap javadoc updates for IdentityException.
   Added note to System.identityHashCode to include value objects.
 - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException
   Add APINote and javadoc for IdentityException where it will be useful to know.
   Updated Objects.hasIdentity to return true for non-null reference to identity class; else false
   Added Objects.isValueObject to return true for non-null reference to value class; else false
   Updated tests for value objects.

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

Changes: https://git.openjdk.org/valhalla/pull/1327/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1327&range=06
  Stats: 250 lines in 11 files changed: 193 ins; 14 del; 43 mod
  Patch: https://git.openjdk.org/valhalla/pull/1327.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1327/head:pull/1327

PR: https://git.openjdk.org/valhalla/pull/1327

From rriggs at openjdk.org  Wed Apr 16 17:21:24 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Apr 2025 17:21:24 GMT
Subject: [lworld] RFR: 8350515: [lworld] CheckedType replaced by NullRestricted
Message-ID: <AlLUThHryI0_a_TpMoST0FUyOLgcEkl2_4u5Jky5F0A=.1296bd66-af0a-4dee-a13d-b33c9211b3fa@github.com>

The support for CheckedType is replaced by an explicit attribute for NullRestricted. VarHandles for fields and arrays are updated to match.

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

Commit messages:
 - 8350515: [lworld] CheckedType replaced by NullRestricted

Changes: https://git.openjdk.org/valhalla/pull/1434/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1434&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350515
  Stats: 301 lines in 9 files changed: 9 ins; 227 del; 65 mod
  Patch: https://git.openjdk.org/valhalla/pull/1434.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1434/head:pull/1434

PR: https://git.openjdk.org/valhalla/pull/1434

From liach at openjdk.org  Wed Apr 16 17:27:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 17:27:53 GMT
Subject: [lworld] RFR: 8350515: [lworld] CheckedType replaced by
 NullRestricted
In-Reply-To: <AlLUThHryI0_a_TpMoST0FUyOLgcEkl2_4u5Jky5F0A=.1296bd66-af0a-4dee-a13d-b33c9211b3fa@github.com>
References: <AlLUThHryI0_a_TpMoST0FUyOLgcEkl2_4u5Jky5F0A=.1296bd66-af0a-4dee-a13d-b33c9211b3fa@github.com>
Message-ID: <dS7Yld1sycRDBc-0tZNDAnS03oOizSfhj4RHs7c7URA=.0e065784-72a3-4cb6-bdd8-468275943056@github.com>

On Wed, 16 Apr 2025 17:16:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The support for CheckedType is replaced by an explicit attribute for NullRestricted. VarHandles for fields and arrays are updated to match.

Looks good. Didn't anticipate removal of CheckedType is this easy.

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

Marked as reviewed by liach (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1434#pullrequestreview-2773299419

From fparain at openjdk.org  Wed Apr 16 18:20:01 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 16 Apr 2025 18:20:01 GMT
Subject: [lworld] Integrated: 8354852: [lworld] invalid interval when copying
 elements in arraycopy
In-Reply-To: <qKbYDBCEE9Og_58PrGmwZ6ocSDt85v5YTRJfDbViSNg=.4535784e-b5c1-45b8-b88a-79f5a1581dd3@github.com>
References: <qKbYDBCEE9Og_58PrGmwZ6ocSDt85v5YTRJfDbViSNg=.4535784e-b5c1-45b8-b88a-79f5a1581dd3@github.com>
Message-ID: <5zuYI8xGVUsAgziCYyho2-Wkpsl9G2k97i6oljWA2AQ=.5b1239f0-3403-44d1-aa53-6d5eed0a036f@github.com>

On Wed, 16 Apr 2025 14:02:33 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fixing computation of the interval of values to be copied when array copying is applied to flat arrays.

This pull request has now been integrated.

Changeset: 6b476fa7
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6b476fa7d67bf80591ed86d291b167d3d5ee5c28
Stats:     7 lines in 2 files changed: 3 ins; 0 del; 4 mod

8354852: [lworld] invalid interval when copying elements in arraycopy

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

PR: https://git.openjdk.org/valhalla/pull/1433

From duke at openjdk.org  Thu Apr 17 00:59:00 2025
From: duke at openjdk.org (duke)
Date: Thu, 17 Apr 2025 00:59:00 GMT
Subject: [lworld] Withdrawn: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects
In-Reply-To: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
Message-ID: <OSBPxW93ZeLCXo1QiFQI-FevrPD5IUAIv4zdL1HOj2s=.d6eb0268-1ca5-4e6a-857b-7b1d7911f9fd@github.com>

On Mon, 6 Jan 2025 20:05:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
> Simplified WeakHashMap javadoc updates for IdentityException. 
> Added note to System.identityHashCode to include value objects.
> Added to class javadoc for IdentityHashMap for value objects.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/valhalla/pull/1327

From jbhateja at openjdk.org  Thu Apr 17 10:05:14 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Apr 2025 10:05:14 GMT
Subject: [lworld+vector] Integrated: Merge lworld
Message-ID: <Sd0BR7iYXHTNdP25xNR2XgZxLhKR9igvYmbxZh_K2aY=.3bcddeef-396a-416b-8805-f5419ddfb21e@github.com>

Merge latest lworld code into lworld+vector

Commit Notes:-
=============
- Removed @ImplicitlyConstructibleValue annotation from all VectorPayloadMF* classes.
- Annotated multifield backed payload with @Strict annotation.
- Re-alignment of the new shuffle implementation with multifield-backed payloads.
- Fine tuning to skip over value forwarding vector boxes to handle non-flat payloads with -XX:-UseNonAtomicValueFlattening) in see_through_inline_type.
- Fix in PhaseMacroExpand::eliminate_allocate_node to skip over the elimination of larval allocations.
- New InlineTypeNode Identity transform to forward VectorBoxes tied to oop fields.
  Such patterns are generated during incremental inlining when vector intrinsic call is replaced
  by an equivalent VetorBoxNode. At this point, we don't require rematerializing InlineTypeNode chain
  earlier tied to vector oop returned by intrinsic call.
- Turning off AbortVMOnCompilationFailure for test/hotspot/jtreg/compiler/vectorapi/VectorMemoryAlias.java 
  to avoid test failures due to compilation bailouts related make/finish private buffer intrinsic.

Functional Validation:-
==============

Valhalla JTREG tests configuration tested:-
  1. Default Settings                          [2 FAILURES
compiler/valhalla/inlinetypes/TestFieldNullMarkers.java                                                                                                     compiler/valhalla/inlinetypes/TestLWorld.java  
 ]
  2. With -XX:+DeoptimizeALot -XX:+SafePointALot    [4 FAILURES]
compiler/valhalla/inlinetypes/TestAllocationMergeAndFolding.java
compiler/valhalla/inlinetypes/TestC2CCalls.java
compiler/valhalla/inlinetypes/TestFieldNullMarkers.java
compiler/valhalla/inlinetypes/TestLWorld.java ]

VectorAPI JTREG test configurations tested:-
  1. Default Settings -                                                    [ALL GREEN]
  2. With -XX:+DeoptimizeALot -XX:+SafePointALot    [ Intermittent failures ]
  3. With-XX:-UseNonAtomicValueFlattening                [ALL GREEN except 1 failure compiler/vectorapi/TestReverseByteTransforms.java on KNL]

Additional Notes:-
============
- With the removal of the flat field size capping runtime flag 'InlineTypeMaxFlatSize', all vector payload fields
  by default have a flat layout within concrete vector containers. 
- Since VectorPayloadMF* classes are decorated with LooselyConsistentValue annotation and payload fields are marked
  as @NullRestricted with @Strict field semantics, the only way to prevent payload flattening is through  runtime flag  -XX:-UseNonAtomicValueFlattening.
 
  
Performance:-
============
Fixed redundant boxing hitting performance of almost all vector kernels. After incremental inlining, VectorBox was getting connected to safepoint nodes through a series of InlineTypeNodes, which were materialized from the return value of CallStaticJavaNode IR created for vector intrinsic entry points after parsing.  Removing redundantly materialized InlineTypeNode through an InlineTypeNode::Identity transform directly connects the VectorBoxNode to the Safepoint, thereby enabling box elimination. 

All pending failures will be fixed in subsequent bug-fix pull requests.

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

Commit messages:
 - jcheck failure fixes
 - Merge branch 'lworld' of http://github.com/openjdk/valhalla into merge_lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - JDK 8327435: [lworld+vector] Align existing Vector API support with JEP 401
 - Merge lworld
 - 8319945: [lworld+vector] Fix vector api jtreg crash with "-XX:-EnableVectorSupport"
 - 8319972: [lworld+vector] Enable intrinsification of Unsafe.finishPrivateBuffer.
 - ... and 15 more: https://git.openjdk.org/valhalla/compare/0e899b25...9138e781

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

Changes: https://git.openjdk.org/valhalla/pull/1436/files
  Stats: 12319 lines in 273 files changed: 4936 ins; 2498 del; 4885 mod
  Patch: https://git.openjdk.org/valhalla/pull/1436.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1436/head:pull/1436

PR: https://git.openjdk.org/valhalla/pull/1436

From jbhateja at openjdk.org  Thu Apr 17 10:05:20 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Apr 2025 10:05:20 GMT
Subject: [lworld+vector] Integrated: Merge lworld
In-Reply-To: <Sd0BR7iYXHTNdP25xNR2XgZxLhKR9igvYmbxZh_K2aY=.3bcddeef-396a-416b-8805-f5419ddfb21e@github.com>
References: <Sd0BR7iYXHTNdP25xNR2XgZxLhKR9igvYmbxZh_K2aY=.3bcddeef-396a-416b-8805-f5419ddfb21e@github.com>
Message-ID: <JgP5Fxgbr4LOE4B-bu91aGrHuTSVG3wqcMZ34f926UE=.795a2a43-b1ac-48c2-b508-c9a25523d3fe@github.com>

On Thu, 17 Apr 2025 09:20:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge latest lworld code into lworld+vector
> 
> Commit Notes:-
> =============
> - Removed @ImplicitlyConstructibleValue annotation from all VectorPayloadMF* classes.
> - Annotated multifield backed payload with @Strict annotation.
> - Re-alignment of the new shuffle implementation with multifield-backed payloads.
> - Fine tuning to skip over value forwarding vector boxes to handle non-flat payloads with -XX:-UseNonAtomicValueFlattening) in see_through_inline_type.
> - Fix in PhaseMacroExpand::eliminate_allocate_node to skip over the elimination of larval allocations.
> - New InlineTypeNode Identity transform to forward VectorBoxes tied to oop fields.
>   Such patterns are generated during incremental inlining when vector intrinsic call is replaced
>   by an equivalent VetorBoxNode. At this point, we don't require rematerializing InlineTypeNode chain
>   earlier tied to vector oop returned by intrinsic call.
> - Turning off AbortVMOnCompilationFailure for test/hotspot/jtreg/compiler/vectorapi/VectorMemoryAlias.java 
>   to avoid test failures due to compilation bailouts related make/finish private buffer intrinsic.
> 
> Functional Validation:-
> ==============
> 
> Valhalla JTREG tests configuration tested:-
>   1. Default Settings                          [2 FAILURES
> compiler/valhalla/inlinetypes/TestFieldNullMarkers.java                                                                                                     compiler/valhalla/inlinetypes/TestLWorld.java  
>  ]
>   2. With -XX:+DeoptimizeALot -XX:+SafePointALot    [4 FAILURES]
> compiler/valhalla/inlinetypes/TestAllocationMergeAndFolding.java
> compiler/valhalla/inlinetypes/TestC2CCalls.java
> compiler/valhalla/inlinetypes/TestFieldNullMarkers.java
> compiler/valhalla/inlinetypes/TestLWorld.java ]
> 
> VectorAPI JTREG test configurations tested:-
>   1. Default Settings -                                                    [ALL GREEN]
>   2. With -XX:+DeoptimizeALot -XX:+SafePointALot    [ Intermittent failures ]
>   3. With-XX:-UseNonAtomicValueFlattening                [ALL GREEN except 1 failure compiler/vectorapi/TestReverseByteTransforms.java on KNL]
> 
> Additional Notes:-
> ============
> - With the removal of the flat field size capping runtime flag 'InlineTypeMaxFlatSize', all vector payload fields
>   by default have a flat layout within concrete vector containers. 
> - Since VectorPayloadMF* classes are decorated with LooselyConsistentValue annotation and payload fields are marked
>   as @NullRestricted with @Strict field semantics, the only way to prevent p...

This pull request has now been integrated.

Changeset: 50897b28
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/50897b2885b98977fbfef5bc522847be099e289c
Stats:     980397 lines in 14148 files changed: 465686 ins; 425709 del; 89002 mod

Merge lworld

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

PR: https://git.openjdk.org/valhalla/pull/1436

From jatin.bhateja at intel.com  Thu Apr 17 10:14:20 2025
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Thu, 17 Apr 2025 10:14:20 +0000
Subject: Merge lworld into lworld+vector
Message-ID: <PH8PR11MB7967B3D0FB71AADCEFDCF9A7E8BC2@PH8PR11MB7967.namprd11.prod.outlook.com>

Hi All,

I have just merged the latest lworld code into lworld+vector branch after 3+ months.

PR                 : https://github.com/openjdk/valhalla/pull/1436
Commit     :  https://github.com/openjdk/valhalla/commit/50897b2885b98977fbfef5bc522847be099e289c

There are some jtreg failures with different validation configurations after this merge which I plan to fix in subsequent bug fix PRs.

Please refer to the following commit notes for details.

Best Regards,
Jatin

Commit Notes:-

  *   Removed @ImplicitlyConstructibleValue annotation from all VectorPayloadMF* classes.
  *   Annotated multifield backed payload with @strict<https://github.com/strict> annotation.
  *   Re-alignment of the new shuffle implementation with multifield-backed payloads.
  *   Fine tuning to skip over value forwarding vector boxes to handle non-flat payloads with -XX:-UseNonAtomicValueFlattening) in see_through_inline_type.
  *   Fix in PhaseMacroExpand::eliminate_allocate_node to skip over the elimination of larval allocations.
  *   New InlineTypeNode Identity transform to forward VectorBoxes tied to oop fields.
Such patterns are generated during incremental inlining when vector intrinsic call is replaced
by an equivalent VetorBoxNode. At this point, we don't require rematerializing InlineTypeNode chain
earlier tied to vector oop returned by intrinsic call.
  *   Turning off AbortVMOnCompilationFailure for test/hotspot/jtreg/compiler/vectorapi/VectorMemoryAlias.java
to avoid test failures due to compilation bailouts related make/finish private buffer intrinsic.

Functional Validation:-
Valhalla JTREG tests configuration tested:-

  1.  Default Settings [2 FAILURES
compiler/valhalla/inlinetypes/TestFieldNullMarkers.java compiler/valhalla/inlinetypes/TestLWorld.java
]
  2.  With -XX:+DeoptimizeALot -XX:+SafePointALot [4 FAILURES]
compiler/valhalla/inlinetypes/TestAllocationMergeAndFolding.java
compiler/valhalla/inlinetypes/TestC2CCalls.java
compiler/valhalla/inlinetypes/TestFieldNullMarkers.java
compiler/valhalla/inlinetypes/TestLWorld.java ]
VectorAPI JTREG test configurations tested:-

  1.  Default Settings - [ALL GREEN]
  2.  With -XX:+DeoptimizeALot -XX:+SafePointALot [ Intermittent failures ]
  3.  With-XX:-UseNonAtomicValueFlattening [ALL GREEN except 1 failure compiler/vectorapi/TestReverseByteTransforms.java on KNL]

Additional Notes:-

  *   With the removal of the flat field size capping runtime flag 'InlineTypeMaxFlatSize', all vector payload fields
by default have a flat layout within concrete vector containers.
  *   Since VectorPayloadMF* classes are decorated with LooselyConsistentValue annotation and payload fields are marked
as @NullRestricted with @strict<https://github.com/strict> field semantics, the only way to prevent payload flattening is through runtime flag -XX:-UseNonAtomicValueFlattening.

Performance:-
Fixed redundant boxing hitting performance of almost all vector kernels. After incremental inlining, VectorBox was getting connected to safepoint nodes through a series of InlineTypeNodes, which were materialized from the return value of CallStaticJavaNode IR created for vector intrinsic entry points after parsing. Removing redundantly materialized InlineTypeNode through an InlineTypeNode::Identity transform directly connects the VectorBoxNode to the Safepoint, thereby enabling box elimination.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250417/d65de787/attachment.htm>

From qamai at openjdk.org  Thu Apr 17 17:03:36 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 17 Apr 2025 17:03:36 GMT
Subject: [lworld] RFR: 8354981: [lworld] Atomic flat stores need preceding
 CPUMemBar
Message-ID: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>

Hi,

Atomic flat stores cover many memory slices. As a result, it needs a preceding CPUMemBar or else it only takes the slice of the first field as its memory input, which is incorrect.

I don't know how to make a regression test for this. I encounter this crash while working on JDK-8335256. The crash was due to the memory input of the flat store gets split during escape analysis. The compiler then tries looking at the flat stores, which is vastly different from what it expects.

Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - Atomic flat store needs a preceding barrier

Changes: https://git.openjdk.org/valhalla/pull/1437/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354981
  Stats: 38 lines in 1 file changed: 15 ins; 16 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/1437.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1437/head:pull/1437

PR: https://git.openjdk.org/valhalla/pull/1437

From rriggs at openjdk.org  Thu Apr 17 18:59:08 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 18:59:08 GMT
Subject: [lworld] Integrated: 8350515: [lworld] CheckedType replaced by
 NullRestricted
In-Reply-To: <AlLUThHryI0_a_TpMoST0FUyOLgcEkl2_4u5Jky5F0A=.1296bd66-af0a-4dee-a13d-b33c9211b3fa@github.com>
References: <AlLUThHryI0_a_TpMoST0FUyOLgcEkl2_4u5Jky5F0A=.1296bd66-af0a-4dee-a13d-b33c9211b3fa@github.com>
Message-ID: <_03xtatJEC56X2n0HWXocrAkwdrAe0KoAAx5iFHAj6A=.b848bf68-1de8-4749-a76b-24379a968485@github.com>

On Wed, 16 Apr 2025 17:16:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The support for CheckedType is replaced by an explicit attribute for NullRestricted. VarHandles for fields and arrays are updated to match.

This pull request has now been integrated.

Changeset: 841c8510
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/841c8510e2cefb81894bd948ed9214e6623ee590
Stats:     301 lines in 9 files changed: 9 ins; 227 del; 65 mod

8350515: [lworld] CheckedType replaced by NullRestricted

Reviewed-by: liach

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

PR: https://git.openjdk.org/valhalla/pull/1434

From matsaave at openjdk.org  Thu Apr 17 20:25:18 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 17 Apr 2025 20:25:18 GMT
Subject: [lworld] RFR: 8354694: [lworld] Refactor AssertUnsetFields to Early
 Larval Frame
Message-ID: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>

This patch adds refactors so the runtime aligns with the new strict field initialization spec (https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html). The stackmap table entry `AssertUnsetFields` is now referred to as `Early_Larval` and it follows a new format where it is a frame that encompasses a base frame.

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

Commit messages:
 - Chen comment
 - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame

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

PR: https://git.openjdk.org/valhalla/pull/1435

From liach at openjdk.org  Thu Apr 17 20:25:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 20:25:19 GMT
Subject: [lworld] RFR: 8354694: [lworld] Refactor AssertUnsetFields to
 Early Larval Frame
In-Reply-To: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
References: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
Message-ID: <h-kW5vLadpKCkWaQi-0zcNIDIEemvjJR1jzwta_2L1c=.30e608a0-d9ba-4953-a6af-d3201d3fee9f@github.com>

On Wed, 16 Apr 2025 21:48:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch adds refactors so the runtime aligns with the new strict field initialization spec (https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html). The stackmap table entry `AssertUnsetFields` is now referred to as `Early_Larval` and it follows a new format where it is a frame that encompasses a base frame.

We might need a switch condition based on the preview status.

src/hotspot/share/classfile/stackMapTable.cpp line 298:

> 296:     _parsed_frame_count++;
> 297:   }
> 298: 

If we have no early_larval wrapping, and there is no more `uninitializedThis` in locals, we implicitly set unset fields to empty. See last sentence in section 4.7.4.

So for control flow like:


if (check) {} else {}
this.strictField = xxx;
super();
if (check1) {} else {}

The frame at first then-else merge has `strictField` unset, but the frame at 2nd else branch off must not be wrapped in early_larval, and verifier must accordingly clear the unset fields.

src/hotspot/share/classfile/stackMapTable.cpp line 358:

> 356:   u2 offset_delta = _stream->get_u2(CHECK_NULL);
> 357: 
> 358:   if (frame_type < EARLY_LARVAL) {

Here this can just be
Suggestion:

  if (frame_type < SAME_LOCALS_1_STACK_ITEM_EXTENDED) {

the case where it is `== EARLY_LARVAL` is already handled earlier, and you don't want this to accidentally handle newer frame types that nest other frames.

src/hotspot/share/classfile/verifier.cpp line 494:

> 492:       break;
> 493:     case STRICT_FIELDS_MISMATCH:
> 494:     ss->print("Current frame's strict instance fields not compatible with stackmap.");

Suggestion:

      ss->print("Current frame's strict instance fields not compatible with stackmap.");

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

PR Review: https://git.openjdk.org/valhalla/pull/1435#pullrequestreview-2774630303
PR Review Comment: https://git.openjdk.org/valhalla/pull/1435#discussion_r2048270388
PR Review Comment: https://git.openjdk.org/valhalla/pull/1435#discussion_r2048268059
PR Review Comment: https://git.openjdk.org/valhalla/pull/1435#discussion_r2048275741

From matsaave at openjdk.org  Thu Apr 17 20:25:19 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 17 Apr 2025 20:25:19 GMT
Subject: [lworld] RFR: 8354694: [lworld] Refactor AssertUnsetFields to
 Early Larval Frame
In-Reply-To: <h-kW5vLadpKCkWaQi-0zcNIDIEemvjJR1jzwta_2L1c=.30e608a0-d9ba-4953-a6af-d3201d3fee9f@github.com>
References: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
 <h-kW5vLadpKCkWaQi-0zcNIDIEemvjJR1jzwta_2L1c=.30e608a0-d9ba-4953-a6af-d3201d3fee9f@github.com>
Message-ID: <v6EDinKZhB4l2atORCjvZgAumOBlzU0UW7cZwxF1KY0=.8a410e05-9277-4c06-a3b6-67a89faf92e6@github.com>

On Thu, 17 Apr 2025 05:41:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch adds refactors so the runtime aligns with the new strict field initialization spec (https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html). The stackmap table entry `AssertUnsetFields` is now referred to as `Early_Larval` and it follows a new format where it is a frame that encompasses a base frame.
>
> src/hotspot/share/classfile/stackMapTable.cpp line 358:
> 
>> 356:   u2 offset_delta = _stream->get_u2(CHECK_NULL);
>> 357: 
>> 358:   if (frame_type < EARLY_LARVAL) {
> 
> Here this can just be
> Suggestion:
> 
>   if (frame_type < SAME_LOCALS_1_STACK_ITEM_EXTENDED) {
> 
> the case where it is `== EARLY_LARVAL` is already handled earlier, and you don't want this to accidentally handle newer frame types that nest other frames.

I think you have it backwards, `EARLY_LARVAL` is less than `SAME_LOCALS_1_STACK_ITEM_EXTENDED`. Your suggestion would include `frame == EARLY_LARVAL` but either way this case is caught and throws an error before this.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1435#discussion_r2049537491

From chen.l.liang at oracle.com  Fri Apr 18 22:55:31 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 18 Apr 2025 22:55:31 +0000
Subject: Preview features and class file formats
Message-ID: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Alex and others,
I am currently enhancing java.lang.reflect.AccessFlag to be able to handle access flags introduced by preview features of the runtime Java SE; for example, project valhalla recognizes ACC_IDENTITY and ACC_STRICT_INIT when running with preview features enabled.

In AccessFlag, there are two APIs: locations() and locations(ClassFileFormatVersion). Currently, both are affected by the enabling of preview features: when preview features are enabled, for both new flags, both locations() and locations(ClassFileFormatVersion.RELEASE_25) (where RELEASE_25 is ClassFileFormatVersion.current()) return their supported locations as preview features; otherwise, they report they support no location. However, I felt that was wrong: when preview features are enabled, applications should still be able to obtain right reflective information applicable to 69.0 class files.

I have been looking at java.lang.reflect.ClassFileFormatVersion, and it seems the versions here never represent class file versions that depend on preview features of specific versions of the Java SE platform. My logical conclusion was that for these flags, locations(ClassFileFormatVersion.RELEASE_25) should report they support no location even when preview features are enabled; ClassFileFormatVersion.RELEASE_25 represents the class file format 69.0, which does not support the new flags, instead of 69.65535. In addition, it does not make sense for locations(ClassFileFormatVersion.RELEASE_25) to differ for a preview-enabled Java SE runtime 25 and any Java SE runtime of a future Java SE release, whether or not preview features are enabled.

Are my understandings of class file format versions and treatment of those APIs correct?

Regards,
Chen Liang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250418/f18c0173/attachment.htm>

From alex.buckley at oracle.com  Sat Apr 19 00:28:03 2025
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 18 Apr 2025 17:28:03 -0700
Subject: Preview features and class file formats
In-Reply-To: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>

On 4/18/2025 3:55 PM, Chen Liang wrote:
> In AccessFlag, there are two APIs: locations() and 
> locations(ClassFileFormatVersion). Currently, both are affected by
> the enabling of preview features: when preview features are enabled,
> for both new flags, both locations() and 
> locations(ClassFileFormatVersion.RELEASE_25) return their supported
> locations as preview features; otherwise, they report they support
> no location. However, I felt that was wrong: when preview features
> are enabled, applications should still be able to obtain right
> reflective information applicable to 69.0 class files.
I wasn't familiar with AccessFlag and ClassFileFormatVersion, but I see 
they were introduced in Java 20 with the intent of accurately modeling 
class file versions and artifacts.

It strikes me as an oversight that for ClassFileFormatVersion, "this 
enum only models the major version". This major-only design decision 
prevents an enum constant RELEASE_25_PREVIEW that models 69.65535. Such 
an enum constant would completely answer the question of what 
locations(ClassFileFormatVersion) should return.

If all we have is RELEASE_25, then I agree with you that uniformly 
returning "no location" is the right answer -- even if preview features 
are enabled. Having reflective APIs vary their answer based on whether 
preview features are enabled is possible but inessential.

As you say, having locations(RELEASE_25) return <<some locations>> on 
JDK 25 _when preview features are enabled_ is inconsistent with the 
future. Roll forward to JDK 33, enable preview features, and call 
locations(RELEASE_25) again: the preview features are different than in 
25, so it doesn't make sense to still answer <<some locations>>. Even if 
it did make sense, we don't want a future JDK (33) to have to remember 
the semantics of preview features from a prior JDK (25).


JEP 12 contemplates "reflective preview APIs" that expose in-preview 
aspects of classes, fields, etc, without requiring preview features to 
be enabled; the expectation is that reflective preview APIs are upgraded 
to permanent APIs later. Examples were Class::isRecord in Java 14 and 
ImportTree::isModule in Java 24. You could in theory introduce a 
reflective preview API like `supportsIdentityFlag()` on 
java.lang.reflect.Field (just an illustration) ... but the nature of the 
reflection that you want to offer for the preview feature ("Is the 
STRICT_INIT flag allowed here?") is _already_ exposed by AccessFlag, a 
permanent API, so it would be redundant to introduce a reflective 
preview API.

Alex

From duke at openjdk.org  Sat Apr 19 01:18:01 2025
From: duke at openjdk.org (duke)
Date: Sat, 19 Apr 2025 01:18:01 GMT
Subject: [lworld] Withdrawn: 8350444: Check for verifer error in
 StackMapReader::check_offset()
In-Reply-To: <dJzFIu_vQeMafDc70iSYO2aa5qJJRFlrsAIACiO_CK8=.1284e8ab-b69b-4e63-9ab1-22ad0a8ceb17@github.com>
References: <dJzFIu_vQeMafDc70iSYO2aa5qJJRFlrsAIACiO_CK8=.1284e8ab-b69b-4e63-9ab1-22ad0a8ceb17@github.com>
Message-ID: <PFFbf7eRGIPXBLYvk2MaIoI6NYBZw7KnDV5vJvLULNc=.6ee06f7d-5165-42ef-8f03-718151428369@github.com>

On Fri, 21 Feb 2025 17:24:31 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch upstreams a change from mainline that is needed to implement strict fields. 
> Originally reviewed-by: coleenp, dholmes

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/valhalla/pull/1372

From qamai at openjdk.org  Sat Apr 19 18:44:04 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 19 Apr 2025 18:44:04 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect declared_nonstatic_fields
 computation
Message-ID: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>

Hi,

This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.

Please kindly review, thanks a lot.

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

Commit messages:
 - move declared_nonstatic_fields to ciInstanceKlass

Changes: https://git.openjdk.org/valhalla/pull/1438/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355076
  Stats: 246 lines in 4 files changed: 92 ins; 89 del; 65 mod
  Patch: https://git.openjdk.org/valhalla/pull/1438.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1438/head:pull/1438

PR: https://git.openjdk.org/valhalla/pull/1438

From qamai at openjdk.org  Sat Apr 19 18:47:47 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 19 Apr 2025 18:47:47 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v2]
In-Reply-To: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
Message-ID: <hYbb82RsWHqNY-93C0GFl57MRqgTZHhNzD0VddxoFsk=.5755b514-1d21-4267-a68e-8507ae0c085a@github.com>

> Hi,
> 
> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
> 
> Please kindly review, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  no need to pass the fields

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1438/files
  - new: https://git.openjdk.org/valhalla/pull/1438/files/2c67b27d..17f3de4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1438&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1438&range=00-01

  Stats: 10 lines in 2 files changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1438.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1438/head:pull/1438

PR: https://git.openjdk.org/valhalla/pull/1438

From qamai at openjdk.org  Sun Apr 20 07:27:43 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 20 Apr 2025 07:27:43 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v3]
In-Reply-To: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
Message-ID: <uUDQnTHkx_CqBM0PVrsu-_MLrpUKw6rydahkg1LULKU=.c2ad1dcc-5f2b-42df-90af-8c0be946663b@github.com>

> Hi,
> 
> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
> 
> Please kindly review, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  small adjustments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1438/files
  - new: https://git.openjdk.org/valhalla/pull/1438/files/17f3de4c..20d98530

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1438&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1438&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1438.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1438/head:pull/1438

PR: https://git.openjdk.org/valhalla/pull/1438

From chen.l.liang at oracle.com  Mon Apr 21 04:13:19 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 21 Apr 2025 04:13:19 +0000
Subject: Preview features and class file formats
In-Reply-To: <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>
References: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>
Message-ID: <IA3SPRMB0018BBAE125A35DB2D79A001A2B82@IA3SPRMB0018.namprd10.prod.outlook.com>

Thanks, Alex, for your detailed response!

For the lack of PREVIEW enum constants in ClassFileFormatVersion or javax.lang.model.SourceVersion, I believe that is a deliberate choice to indicate that each Java SE release must not support any preview feature from any other release. I have examined where SourceVersion is used as method parameters - they are currently used for their static methods of isName() and isKeyword(), both of which currently do not face a scenario where for a specific source version, when preview features are enabled, these methods would behave differently, even though such a scenario is considered in JEP 12. I believe we are facing a new scenario; however, SourceVersion APIs cannot quite follow suit from my AccessFlag handling, because compiling a program to use preview features happens on each compilation task instead of the whole Java Runtime Environment, and we might consider another solution that unifies these two usages.

In addition, I wonder about the extent of reflective preview APIs: starting with the simplest, the new AccessFlag enum constants from Value Objects (Preview) JEP must be reflective - users may obtain them from accessFlag() reflection methods already. Meanwhile, the ClassFile API also models certain preview class file constructs - for example, Strict Fields (Preview), a draft JEP, introduces updated StackMapTable attributes. I think the new accessors on the attribute for the new properties can be reflective preview features, like the preview visitors provided in javax.lang.model.util; however, I am not sure if the factory methods that construct new StackMapTable attributes with these new properties are still eligible as reflective preview APIs. They don't seem necessary for parsing preview class files, and look more like essential preview APIs instead. It all comes down to one question: does it make sense for class file generators to generate preview class files when the Java Runtime Environment does not have preview features enabled?

Regards, Chen

________________________________
From: Alex Buckley <alex.buckley at oracle.com>
Sent: Friday, April 18, 2025 7:28 PM
To: Chen Liang <chen.l.liang at oracle.com>; valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>; compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: Re: Preview features and class file formats

On 4/18/2025 3:55 PM, Chen Liang wrote:
> In AccessFlag, there are two APIs: locations() and
> locations(ClassFileFormatVersion). Currently, both are affected by
> the enabling of preview features: when preview features are enabled,
> for both new flags, both locations() and
> locations(ClassFileFormatVersion.RELEASE_25) return their supported
> locations as preview features; otherwise, they report they support
> no location. However, I felt that was wrong: when preview features
> are enabled, applications should still be able to obtain right
> reflective information applicable to 69.0 class files.
I wasn't familiar with AccessFlag and ClassFileFormatVersion, but I see
they were introduced in Java 20 with the intent of accurately modeling
class file versions and artifacts.

It strikes me as an oversight that for ClassFileFormatVersion, "this
enum only models the major version". This major-only design decision
prevents an enum constant RELEASE_25_PREVIEW that models 69.65535. Such
an enum constant would completely answer the question of what
locations(ClassFileFormatVersion) should return.

If all we have is RELEASE_25, then I agree with you that uniformly
returning "no location" is the right answer -- even if preview features
are enabled. Having reflective APIs vary their answer based on whether
preview features are enabled is possible but inessential.

As you say, having locations(RELEASE_25) return <<some locations>> on
JDK 25 _when preview features are enabled_ is inconsistent with the
future. Roll forward to JDK 33, enable preview features, and call
locations(RELEASE_25) again: the preview features are different than in
25, so it doesn't make sense to still answer <<some locations>>. Even if
it did make sense, we don't want a future JDK (33) to have to remember
the semantics of preview features from a prior JDK (25).


JEP 12 contemplates "reflective preview APIs" that expose in-preview
aspects of classes, fields, etc, without requiring preview features to
be enabled; the expectation is that reflective preview APIs are upgraded
to permanent APIs later. Examples were Class::isRecord in Java 14 and
ImportTree::isModule in Java 24. You could in theory introduce a
reflective preview API like `supportsIdentityFlag()` on
java.lang.reflect.Field (just an illustration) ... but the nature of the
reflection that you want to offer for the preview feature ("Is the
STRICT_INIT flag allowed here?") is _already_ exposed by AccessFlag, a
permanent API, so it would be redundant to introduce a reflective
preview API.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250421/44954f81/attachment.htm>

From alex.buckley at oracle.com  Mon Apr 21 14:44:21 2025
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 21 Apr 2025 07:44:21 -0700
Subject: Preview features and class file formats
In-Reply-To: <IA3SPRMB0018BBAE125A35DB2D79A001A2B82@IA3SPRMB0018.namprd10.prod.outlook.com>
References: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>
 <IA3SPRMB0018BBAE125A35DB2D79A001A2B82@IA3SPRMB0018.namprd10.prod.outlook.com>
Message-ID: <d1427950-4f6f-44a7-af32-c4cec4b3ecb5@oracle.com>

On 4/20/2025 9:13 PM, Chen Liang wrote:
> In addition, I wonder about the extent of reflective preview APIs: 
> starting with the simplest, the new AccessFlag enum constants from Value 
> Objects (Preview) JEP must be reflective - users may obtain them from 
> accessFlag() reflection methods already. Meanwhile, the ClassFile API 
> also models certain preview class file constructs - for example, Strict 
> Fields (Preview), a draft JEP, introduces updated StackMapTable 
> attributes. I think the new accessors on the attribute for the new 
> properties can be reflective preview features, like the preview visitors 
> provided in javax.lang.model.util; however, I am not sure if the factory 
> methods that construct new StackMapTable attributes with these new 
> properties are still eligible as reflective preview APIs. They don't 
> seem necessary for parsing preview class files, and look more like 
> essential preview APIs instead. It all comes down to one question: does 
> it make sense for class file generators to generate preview class files 
> when the Java Runtime Environment does not have preview features enabled?

This is getting into fairly fine distinctions about the functionality of 
specific APIs, but I think the short answer to your question is "Yes".

As you suggest, the notion of a _reflective_ preview API is usually 
about consuming pre-existing class file artifacts (and, crucially, doing 
so when preview features are not enabled at run time) rather than 
producing new artifacts.

For example, on JDK 16, before Sealed Classes were permanent, a 
framework that used a reflective preview API to ask "Is this class 
sealed?" did so because it expected someone else to have generated a 
<<major>>.65535 class file with a PermittedSubclasses attribute.

In general, though, the "someone else" could be another framework ... or 
even the same one! Imagine: The end user doesn't have to enable preview 
features but behind the scenes, the framework both produces and consumes 
class files that exploit preview features. (Obviously this speaks to 
scenarios where the class files are invisible to the end user, not 
persisted to disk where other tools might pick them up, etc.)

We offer this flexibility to framework developers so they can get a head 
start on utilizing the features and provide feedback on them while 
they're still in preview and able to change.

It's something of a safe choice to evolve reflective APIs in java.* and 
javax.* with normal preview APIs (whether classes, methods, or fields), 
but I would be happy to see more additions of reflective preview APIs 
that give framework developers the earliest possible chance at use and 
feedback.

Alex

From chen.l.liang at oracle.com  Mon Apr 21 16:20:57 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 21 Apr 2025 16:20:57 +0000
Subject: Preview features and class file formats
In-Reply-To: <d1427950-4f6f-44a7-af32-c4cec4b3ecb5@oracle.com>
References: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>
 <IA3SPRMB0018BBAE125A35DB2D79A001A2B82@IA3SPRMB0018.namprd10.prod.outlook.com>
 <d1427950-4f6f-44a7-af32-c4cec4b3ecb5@oracle.com>
Message-ID: <SJ2PR10MB766945B07CD15E3D982BFEB2A2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>

Thanks Alex, this explanation is enlightening! Indeed, it makes sense that such access is necessary even if preview features are not enabled on the runtime - for example, javac still wishes to access such information even if its runtime itself is not in preview. Same for other class file processors.

That said, I wish to come back to the non SourceVersion/ClassFileFormatVersion-aware query methods - should they just return the behavior when preview is enabled in the current release even when preview is not enabled?

Coming back to the JEP 12 example of reserving _ as a keyword, the SourceVersion.isIdentifier API will return false for _ in an implementation of Java SE 8, regardless if the runtime has preview features enabled or not, instead of only declaring that _ is not an identifier when preview is enabled (and the API does not have access to that information - it does not know if the caller wishes to compile under preview or not, it only knows if the current running VM is enabling preview VM features). Same problem happens with AccessFlag: the API doesn't know if the caller wishes to generate preview class files in a non-preview runtime environment.
________________________________
From: Alex Buckley <alex.buckley at oracle.com>
Sent: Monday, April 21, 2025 9:44 AM
To: Chen Liang <chen.l.liang at oracle.com>; valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>; compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: Re: Preview features and class file formats

On 4/20/2025 9:13 PM, Chen Liang wrote:
> In addition, I wonder about the extent of reflective preview APIs:
> starting with the simplest, the new AccessFlag enum constants from Value
> Objects (Preview) JEP must be reflective - users may obtain them from
> accessFlag() reflection methods already. Meanwhile, the ClassFile API
> also models certain preview class file constructs - for example, Strict
> Fields (Preview), a draft JEP, introduces updated StackMapTable
> attributes. I think the new accessors on the attribute for the new
> properties can be reflective preview features, like the preview visitors
> provided in javax.lang.model.util; however, I am not sure if the factory
> methods that construct new StackMapTable attributes with these new
> properties are still eligible as reflective preview APIs. They don't
> seem necessary for parsing preview class files, and look more like
> essential preview APIs instead. It all comes down to one question: does
> it make sense for class file generators to generate preview class files
> when the Java Runtime Environment does not have preview features enabled?

This is getting into fairly fine distinctions about the functionality of
specific APIs, but I think the short answer to your question is "Yes".

As you suggest, the notion of a _reflective_ preview API is usually
about consuming pre-existing class file artifacts (and, crucially, doing
so when preview features are not enabled at run time) rather than
producing new artifacts.

For example, on JDK 16, before Sealed Classes were permanent, a
framework that used a reflective preview API to ask "Is this class
sealed?" did so because it expected someone else to have generated a
<<major>>.65535 class file with a PermittedSubclasses attribute.

In general, though, the "someone else" could be another framework ... or
even the same one! Imagine: The end user doesn't have to enable preview
features but behind the scenes, the framework both produces and consumes
class files that exploit preview features. (Obviously this speaks to
scenarios where the class files are invisible to the end user, not
persisted to disk where other tools might pick them up, etc.)

We offer this flexibility to framework developers so they can get a head
start on utilizing the features and provide feedback on them while
they're still in preview and able to change.

It's something of a safe choice to evolve reflective APIs in java.* and
javax.* with normal preview APIs (whether classes, methods, or fields),
but I would be happy to see more additions of reflective preview APIs
that give framework developers the earliest possible chance at use and
feedback.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250421/333c9c09/attachment.htm>

From alex.buckley at oracle.com  Mon Apr 21 17:26:58 2025
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 21 Apr 2025 10:26:58 -0700
Subject: Preview features and class file formats
In-Reply-To: <SJ2PR10MB766945B07CD15E3D982BFEB2A2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>
 <IA3SPRMB0018BBAE125A35DB2D79A001A2B82@IA3SPRMB0018.namprd10.prod.outlook.com>
 <d1427950-4f6f-44a7-af32-c4cec4b3ecb5@oracle.com>
 <SJ2PR10MB766945B07CD15E3D982BFEB2A2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <57fef74c-ec2f-411f-9bdd-8b3ef40f8eb7@oracle.com>

On 4/21/2025 9:20 AM, Chen Liang wrote:
> That said, I wish to come back to the non SourceVersion/ 
> ClassFileFormatVersion-aware query methods - should they just return the 
> behavior when preview is enabled in the current release even when 
> preview is not enabled?

I thought we had agreed that if version-sensitive query methods can only 
be made aware of "25", not "25 with preview enabled", then their results 
should indicate the permanent behavior of 25 _regardless of whether the 
Java runtime was started with --enable-preview_.

> Coming back to the JEP 12 example of reserving _ as a keyword, the 
> SourceVersion.isIdentifier API will return false for _ in an 
> implementation of Java SE 8, regardless if the runtime has preview 
> features enabled or not, instead of only declaring that _ is not an 
> identifier when preview is enabled 

That's tricky because _ in 8 caused a warning but was technically legal. 
We knew there would be code compiled and run on 8 for many years, and 
did not wish to break it. _ only caused an error in 8 with 
--enable-preview. So, consistent with my cautious position above, 
SourceVersion.isIdentifier("_") would have returned true on an 8 runtime 
_regardless of whether the runtime was started with --enable-preview_.

Alex

From chen.l.liang at oracle.com  Mon Apr 21 20:53:10 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 21 Apr 2025 20:53:10 +0000
Subject: Preview features and class file formats
In-Reply-To: <57fef74c-ec2f-411f-9bdd-8b3ef40f8eb7@oracle.com>
References: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>
 <IA3SPRMB0018BBAE125A35DB2D79A001A2B82@IA3SPRMB0018.namprd10.prod.outlook.com>
 <d1427950-4f6f-44a7-af32-c4cec4b3ecb5@oracle.com>
 <SJ2PR10MB766945B07CD15E3D982BFEB2A2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <57fef74c-ec2f-411f-9bdd-8b3ef40f8eb7@oracle.com>
Message-ID: <SJ2PR10MB76694145AD069F9EA56CCF9AA2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>

Alex, thanks for the Q&A's we have had! Looking at the history, I get one more question about reflective preview APIs:

Per JEP 12, reflective preview APIs do not allow preview features to be used; rather, they allow programs compiled without preview to run correctly in a Java Runtime Environment running with preview features enabled.

I just reviewed the preview APIs introduced for Value Objects JEP: it has a few, such as IdentityException, Objects.requireIdentity, that perform inspection on object instances but are not marked as reflective. I believe they should be marked reflective, as they are critical for non-preview programs to run correctly when preview is enabled (when they can receive value objects, and JVM can throw IdentityException for certain bytecode instructions). Meanwhile, the constructor for IdentityException are all essential preview APIs - they are necessary for the Value Objects feature, but not for non-preview programs to run correctly when preview features are enabled.

Is my rationale for categorizing reflective vs essential preview APIs correct? In particular, can inspection on object instances via getClass() be considered reflection as well?

Regards, Chen
________________________________
From: Alex Buckley <alex.buckley at oracle.com>
Sent: Monday, April 21, 2025 12:26 PM
To: Chen Liang <chen.l.liang at oracle.com>; valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>; compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: Re: Preview features and class file formats

On 4/21/2025 9:20 AM, Chen Liang wrote:
> That said, I wish to come back to the non SourceVersion/
> ClassFileFormatVersion-aware query methods - should they just return the
> behavior when preview is enabled in the current release even when
> preview is not enabled?

I thought we had agreed that if version-sensitive query methods can only
be made aware of "25", not "25 with preview enabled", then their results
should indicate the permanent behavior of 25 _regardless of whether the
Java runtime was started with --enable-preview_.

> Coming back to the JEP 12 example of reserving _ as a keyword, the
> SourceVersion.isIdentifier API will return false for _ in an
> implementation of Java SE 8, regardless if the runtime has preview
> features enabled or not, instead of only declaring that _ is not an
> identifier when preview is enabled

That's tricky because _ in 8 caused a warning but was technically legal.
We knew there would be code compiled and run on 8 for many years, and
did not wish to break it. _ only caused an error in 8 with
--enable-preview. So, consistent with my cautious position above,
SourceVersion.isIdentifier("_") would have returned true on an 8 runtime
_regardless of whether the runtime was started with --enable-preview_.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250421/00e5262e/attachment.htm>

From alex.buckley at oracle.com  Mon Apr 21 21:21:54 2025
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 21 Apr 2025 14:21:54 -0700
Subject: Preview features and class file formats
In-Reply-To: <SJ2PR10MB76694145AD069F9EA56CCF9AA2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>
 <IA3SPRMB0018BBAE125A35DB2D79A001A2B82@IA3SPRMB0018.namprd10.prod.outlook.com>
 <d1427950-4f6f-44a7-af32-c4cec4b3ecb5@oracle.com>
 <SJ2PR10MB766945B07CD15E3D982BFEB2A2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <57fef74c-ec2f-411f-9bdd-8b3ef40f8eb7@oracle.com>
 <SJ2PR10MB76694145AD069F9EA56CCF9AA2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <f9b70be8-4b5d-49ba-ac00-359a987cfcc0@oracle.com>

On 4/21/2025 1:53 PM, Chen Liang wrote:
> Per JEP 12, reflective preview APIs do not allow preview features to be 
> used; rather, they allow programs compiled without preview to run 
> correctly in a Java Runtime Environment running with preview features 
> enabled.

Yes, that's one way of looking at it. The program compiled without 
preview is typically a framework that wants to run everywhere. If a user 
chooses to exploit preview features in their code, by passing 
--enable-preview at compile time and run time, then the framework when 
running on this user's machine can (via reflective preview APIs) 
recognize and adapt to the user's preview-using classes.

For example, when records were previewing in Java 14, a framework that 
recognized a user class as a record (via Class::isRecord, which today 
we'd call a reflective preview API) could deserialize it more 
efficiently than normal classes, since records can't self-reference.

> I just reviewed the preview APIs introduced for Value Objects JEP: it 
> has a few, such as IdentityException, Objects.requireIdentity, that 
> perform inspection on object instances but are not marked as reflective. 
> I believe they should be marked reflective, as they are critical for 
> non-preview programs to run correctly when preview is enabled (when they 
> can receive value objects, and JVM can throw IdentityException for 
> certain bytecode instructions).

Yes. There's little downside in marking a preview API concerned with 
reflection as a reflective (rather than normal) preview API.

> Meanwhile, the constructor for IdentityException are all essential
> preview APIs - they are necessary for the Value Objects feature, but
> not for non-preview programs to run correctly when preview features
> are enabled.

This sounds right.

> In particular, can inspection on object instances via
> getClass() be considered reflection as well?

It is reflection, but I don't see how it connects to the Value Objects 
API you mentioned earlier.

Alex

From liach at openjdk.org  Mon Apr 21 21:24:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 21:24:23 GMT
Subject: [lworld] RFR: 8355227: [lworld] Clarify preview API status for some
 vallhalla APIs
Message-ID: <DmOucRXMHw1sOoSXegWYjN5JWVXF1xDunKRMhyUZORs=.3d81aaae-bf70-4f6a-a347-1a0a4eed9beb@github.com>

Per [JEP 12](https://openjdk.org/jeps/12):

> In order for frameworks to deliver early support for a preview language feature, frameworks should utilize the reflective preview APIs that are co-developed with it. This will allow frameworks to keep up when programs are written to use the permanent version of the language feature.

According to these rules, the `Objects` methods and the `IdentityException` class themselves must be reflective preview APIs: programs compiled without preview feature dependencies that are running with preview features enabled should be able to access these APIs, as at run-time, they may receive value objects and `IdentityException` thrown by the JVM.

The only remaining essential preview APIs are the constructors of `IdentityException`: non-preview programs have no reason to construct them.

In addition, fixed a few JEP feature reference: notably, add reference to [Strict Fields JEP](https://openjdk.org/jeps/8350458).

Also, made ClassFile API new models reflective preview APIs - class file processors wish to process structures from preview class files even if the current runtime is not in preview. This is already happening to javac and javap.

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

Commit messages:
 - 8355227: [lworld] Clarify preview API status for some vallhalla APIs

Changes: https://git.openjdk.org/valhalla/pull/1439/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1439&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355227
  Stats: 19 lines in 6 files changed: 12 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/1439.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1439/head:pull/1439

PR: https://git.openjdk.org/valhalla/pull/1439

From liach at openjdk.org  Mon Apr 21 21:27:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 21:27:46 GMT
Subject: [lworld] RFR: 8355227: [lworld] Clarify preview API status for
 some vallhalla APIs
In-Reply-To: <DmOucRXMHw1sOoSXegWYjN5JWVXF1xDunKRMhyUZORs=.3d81aaae-bf70-4f6a-a347-1a0a4eed9beb@github.com>
References: <DmOucRXMHw1sOoSXegWYjN5JWVXF1xDunKRMhyUZORs=.3d81aaae-bf70-4f6a-a347-1a0a4eed9beb@github.com>
Message-ID: <-38rkYPEK2hEFH7UousxCpZzyoGDgrUkgBJUBLM7BeU=.92f9e8d3-54fb-4d91-ad81-37edb32aaceb@github.com>

On Mon, 21 Apr 2025 21:19:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> Per [JEP 12](https://openjdk.org/jeps/12):
> 
>> In order for frameworks to deliver early support for a preview language feature, frameworks should utilize the reflective preview APIs that are co-developed with it. This will allow frameworks to keep up when programs are written to use the permanent version of the language feature.
> 
> According to these rules, the `Objects` methods and the `IdentityException` class themselves must be reflective preview APIs: programs compiled without preview feature dependencies that are running with preview features enabled should be able to access these APIs, as at run-time, they may receive value objects and `IdentityException` thrown by the JVM.
> 
> The only remaining essential preview APIs are the constructors of `IdentityException`: non-preview programs have no reason to construct them.
> 
> In addition, fixed a few JEP feature reference: notably, add reference to [Strict Fields JEP](https://openjdk.org/jeps/8350458).
> 
> Also, made ClassFile API new models reflective preview APIs - class file processors wish to process structures from preview class files even if the current runtime is not in preview. This is already happening to javac and javap.

See thread: https://mail.openjdk.org/pipermail/valhalla-dev/2025-April/014045.html

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

PR Comment: https://git.openjdk.org/valhalla/pull/1439#issuecomment-2819536368

From forax at univ-mlv.fr  Tue Apr 22 09:12:00 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 22 Apr 2025 11:12:00 +0200 (CEST)
Subject: Preview features and class file formats
In-Reply-To: <f9b70be8-4b5d-49ba-ac00-359a987cfcc0@oracle.com>
References: <SJ2PR10MB7669ECCB47C7CAF951A9F155A2BF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <fe387e0d-f105-43cf-9f46-96f2f8cdaeff@oracle.com>
 <IA3SPRMB0018BBAE125A35DB2D79A001A2B82@IA3SPRMB0018.namprd10.prod.outlook.com>
 <d1427950-4f6f-44a7-af32-c4cec4b3ecb5@oracle.com>
 <SJ2PR10MB766945B07CD15E3D982BFEB2A2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <57fef74c-ec2f-411f-9bdd-8b3ef40f8eb7@oracle.com>
 <SJ2PR10MB76694145AD069F9EA56CCF9AA2B82@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <f9b70be8-4b5d-49ba-ac00-359a987cfcc0@oracle.com>
Message-ID: <1736438440.239506805.1745313120289.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Alex Buckley" <alex.buckley at oracle.com>
> To: "Chen Liang" <chen.l.liang at oracle.com>, "valhalla-dev" <valhalla-dev at openjdk.org>, "compiler-dev"
> <compiler-dev at openjdk.org>
> Sent: Monday, April 21, 2025 11:21:54 PM
> Subject: Re: Preview features and class file formats

[...]

> 
> For example, when records were previewing in Java 14, a framework that
> recognized a user class as a record (via Class::isRecord, which today
> we'd call a reflective preview API) could deserialize it more
> efficiently than normal classes, since records can't self-reference.

??

A record can reference itself, 

public class RecordSelfReference {
  record A(A a) {
    A {
      a = this;
    }
  }

  public static void main(String[] args) {
    var a = new A(null);
    System.out.println(a);
  }
}

It's useless because toString(), equals() and hashCode() go into an infinite loop, but you can.

> 
> Alex

R?mi

From thartmann at openjdk.org  Tue Apr 22 11:17:57 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 22 Apr 2025 11:17:57 GMT
Subject: [lworld] RFR: 8353195: [lworld] Several failures with
 -XX:+UseNullableValueFlattening
Message-ID: <m4NNFv0KRIstfv4eMY126B5C7Vm6ORNxcbFA8_mvJYE=.f044ef7c-e703-4ab4-bd3d-2bd7afabb306@github.com>

This PR fixes several issues when running tests with `-XX:+UseNullableValueFlattening` (see JBS description and linked bugs for details).

While testing I found an intermittent SIGSEGV on AArch64 and spent a few days debugging without major progress. It seems to be a GC related issue. I filed [JDK-8355277](https://bugs.openjdk.org/browse/JDK-8355277) for this and will investigate separately.

All compiler tests now pass with `-XX:+UseNullableValueFlattening` on my machine. I'll run more testing with [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865).

Thanks,
Tobias

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

Commit messages:
 - Cleanup
 - Adjusted comment
 - Merge branch 'lworld' into JDK-8353195
 - Some more fixes
 - Barrier ad file fix
 - More fixes
 - First prototype

Changes: https://git.openjdk.org/valhalla/pull/1428/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1428&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353195
  Stats: 258 lines in 16 files changed: 175 ins; 40 del; 43 mod
  Patch: https://git.openjdk.org/valhalla/pull/1428.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1428/head:pull/1428

PR: https://git.openjdk.org/valhalla/pull/1428

From thartmann at openjdk.org  Tue Apr 22 12:02:55 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 22 Apr 2025 12:02:55 GMT
Subject: [lworld] Integrated: 8353195: [lworld] Several failures with
 -XX:+UseNullableValueFlattening
In-Reply-To: <m4NNFv0KRIstfv4eMY126B5C7Vm6ORNxcbFA8_mvJYE=.f044ef7c-e703-4ab4-bd3d-2bd7afabb306@github.com>
References: <m4NNFv0KRIstfv4eMY126B5C7Vm6ORNxcbFA8_mvJYE=.f044ef7c-e703-4ab4-bd3d-2bd7afabb306@github.com>
Message-ID: <LSQmiQ_Xe4tb_UYwTiwVoEoCrUTJgiV6dqZEfMRhRnU=.be41d208-e2f8-40a9-bcd7-7a14f861b9b6@github.com>

On Fri, 11 Apr 2025 13:24:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This PR fixes several issues when running tests with `-XX:+UseNullableValueFlattening` (see JBS description and linked bugs for details).
> 
> While testing I found an intermittent SIGSEGV on AArch64 and spent a few days debugging without major progress. It seems to be a GC related issue. I filed [JDK-8355277](https://bugs.openjdk.org/browse/JDK-8355277) for this and will investigate separately.
> 
> All compiler and runtime Valhalla tests now pass with `-XX:+UseNullableValueFlattening` on my machine. I'll run more testing with [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: b72d63c7
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b72d63c75ebac8ef52dfa96b093b02e208d4faa5
Stats:     258 lines in 16 files changed: 175 ins; 40 del; 43 mod

8353195: [lworld] Several failures with -XX:+UseNullableValueFlattening

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

PR: https://git.openjdk.org/valhalla/pull/1428

From thartmann at openjdk.org  Tue Apr 22 12:15:53 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 22 Apr 2025 12:15:53 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v3]
In-Reply-To: <uUDQnTHkx_CqBM0PVrsu-_MLrpUKw6rydahkg1LULKU=.c2ad1dcc-5f2b-42df-90af-8c0be946663b@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
 <uUDQnTHkx_CqBM0PVrsu-_MLrpUKw6rydahkg1LULKU=.c2ad1dcc-5f2b-42df-90af-8c0be946663b@github.com>
Message-ID: <9Dwsnpu96aqzbz6YBflOZsr1c9pHvpAqHu9zALk0D1Q=.54a1042e-4dd2-4489-9439-cdab0f262f66@github.com>

On Sun, 20 Apr 2025 07:27:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustments

I just fixed something similar with https://github.com/openjdk/valhalla/pull/1428 / [JDK-8353195](https://bugs.openjdk.org/browse/JDK-8353195), see:
https://github.com/openjdk/valhalla/blob/b72d63c75ebac8ef52dfa96b093b02e208d4faa5/src/hotspot/share/ci/ciInstanceKlass.cpp#L530-L532

Isn't that sufficient?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1438#issuecomment-2821136587

From thartmann at openjdk.org  Tue Apr 22 12:23:01 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 22 Apr 2025 12:23:01 GMT
Subject: [lworld] RFR: 8354981: [lworld] Atomic flat stores need preceding
 CPUMemBar
In-Reply-To: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
References: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
Message-ID: <l6gZMt2rCHWjsmCtbqv3Wbq2XU9YWLphqc11IBTxukM=.f6c9afb6-2320-49f4-b116-a7e4b908aacd@github.com>

On Thu, 17 Apr 2025 16:58:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Atomic flat stores cover many memory slices. As a result, it needs a preceding CPUMemBar or else it only takes the slice of the first field as its memory input, which is incorrect.
> 
> I don't know how to make a regression test for this. I encounter this crash while working on JDK-8335256. The crash was due to the memory input of the flat store gets split during escape analysis. The compiler then tries looking at the flat stores, which is vastly different from what it expects.
> 
> Please take a look and leave your reviews, thanks a lot.

That looks good to me! I see that you also fixed the broken control flow. I did the same with https://github.com/openjdk/valhalla/pull/1428 / [JDK-8353195](https://bugs.openjdk.org/browse/JDK-8353195), please merge in the changes and I'll run some testing.

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

PR Review: https://git.openjdk.org/valhalla/pull/1437#pullrequestreview-2783914008

From thartmann at openjdk.org  Tue Apr 22 12:29:57 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 22 Apr 2025 12:29:57 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
Message-ID: <qKkXqohZobA59FuQ1KNSxTT0byLIFCjFEN64WknRWK4=.1f1e2219-fd74-49b7-84e7-4cc8316d01bc@github.com>

On Wed, 9 Apr 2025 17:46:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix wrong results
>  - fix invalid node class: Unlock

Sorry for the delay! I resubmitted testing and will review later this week.

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

PR Review: https://git.openjdk.org/valhalla/pull/1424#pullrequestreview-2783931615

From thartmann at openjdk.org  Tue Apr 22 13:05:55 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 22 Apr 2025 13:05:55 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v3]
In-Reply-To: <uUDQnTHkx_CqBM0PVrsu-_MLrpUKw6rydahkg1LULKU=.c2ad1dcc-5f2b-42df-90af-8c0be946663b@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
 <uUDQnTHkx_CqBM0PVrsu-_MLrpUKw6rydahkg1LULKU=.c2ad1dcc-5f2b-42df-90af-8c0be946663b@github.com>
Message-ID: <BooVikzA38B6VxFAS_eXcNQcR3-4T4Xn8W1hbjQ3C8o=.35d4958b-1f34-4b93-8a74-4d0fbd17e657@github.com>

On Sun, 20 Apr 2025 07:27:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustments

I could also not reproduce [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) (see details in JBS).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1438#issuecomment-2821263420

From qamai at openjdk.org  Tue Apr 22 13:15:06 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 22 Apr 2025 13:15:06 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v3]
In-Reply-To: <BooVikzA38B6VxFAS_eXcNQcR3-4T4Xn8W1hbjQ3C8o=.35d4958b-1f34-4b93-8a74-4d0fbd17e657@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
 <uUDQnTHkx_CqBM0PVrsu-_MLrpUKw6rydahkg1LULKU=.c2ad1dcc-5f2b-42df-90af-8c0be946663b@github.com>
 <BooVikzA38B6VxFAS_eXcNQcR3-4T4Xn8W1hbjQ3C8o=.35d4958b-1f34-4b93-8a74-4d0fbd17e657@github.com>
Message-ID: <DFEZzBDoiAIUl9axzXv-n3GHEYgfNJFAahqmOwsR-xk=.1c380f4d-49b7-4ee9-aaa6-142340940041@github.com>

On Tue, 22 Apr 2025 13:02:56 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small adjustments
>
> I could also not reproduce [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) (see details in JBS).

@TobiHartmann 

> Isn't that sufficient?

It can be. I think, however, it is confusing to have `non_static_fields` referring to different things when a type is a concrete class and when it is an abstract class. I also think that `declared_nonstatic_fields` seems not to be something that is only applicable to value classes. As a result, moving it to `ciInstanceKlass` seems to be a logical move.

> I could also not reproduce [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) (see details in JBS).

I believe you need `@Strict @NullRestricted` so that the field is inlined.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1438#issuecomment-2821291408

From fparain at openjdk.org  Tue Apr 22 13:56:29 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 22 Apr 2025 13:56:29 GMT
Subject: [lworld] Integrated: 8355295: [lworld]
 runtime/valhalla/inlinetypes/VolatileTest.java fails with
 -XX:+UseAtomicValueFlattening
Message-ID: <7ShMIwkUv8nxcI3G4KBbQBiWz8CzvTFz73go-Yqgiyg=.1e42c1ac-671e-435f-872a-bc9717019cab@github.com>

Update test after the semantic change of the volatile keyword (it's now a flattening opt-out again).

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

Commit messages:
 - Update test after volatile semantic change (flattening opt-out)

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

PR: https://git.openjdk.org/valhalla/pull/1440

From fparain at openjdk.org  Tue Apr 22 13:56:29 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 22 Apr 2025 13:56:29 GMT
Subject: [lworld] Integrated: 8355295: [lworld]
 runtime/valhalla/inlinetypes/VolatileTest.java fails with
 -XX:+UseAtomicValueFlattening
In-Reply-To: <7ShMIwkUv8nxcI3G4KBbQBiWz8CzvTFz73go-Yqgiyg=.1e42c1ac-671e-435f-872a-bc9717019cab@github.com>
References: <7ShMIwkUv8nxcI3G4KBbQBiWz8CzvTFz73go-Yqgiyg=.1e42c1ac-671e-435f-872a-bc9717019cab@github.com>
Message-ID: <FFMPmFqrKtv4Hgu1InwUxj-YjtiOtp0Xlt_WcgfeH0I=.1d82bbdd-7eff-44dc-9c46-d6c936681112@github.com>

On Tue, 22 Apr 2025 13:50:34 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Update test after the semantic change of the volatile keyword (it's now a flattening opt-out again).

This pull request has now been integrated.

Changeset: 937fb6a8
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/937fb6a87b28d1f4f038c2ed40aa1a9fa47320c8
Stats:     8 lines in 1 file changed: 0 ins; 7 del; 1 mod

8355295: [lworld] runtime/valhalla/inlinetypes/VolatileTest.java fails with -XX:+UseAtomicValueFlattening

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

PR: https://git.openjdk.org/valhalla/pull/1440

From qamai at openjdk.org  Tue Apr 22 15:47:42 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 22 Apr 2025 15:47:42 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v4]
In-Reply-To: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
Message-ID: <btyhSbWjZIvM8hWVo_lRhJfvuOYwlm0vYvniKCuFFb0=.9bca20e3-f537-4dee-828a-515d50a80f80@github.com>

> Hi,
> 
> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
> 
> Please kindly review, thanks a lot.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'lworld' into declaredfields
 - small adjustments
 - no need to pass the fields
 - move declared_nonstatic_fields to ciInstanceKlass

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

Changes: https://git.openjdk.org/valhalla/pull/1438/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1438&range=03
  Stats: 245 lines in 4 files changed: 89 ins; 89 del; 67 mod
  Patch: https://git.openjdk.org/valhalla/pull/1438.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1438/head:pull/1438

PR: https://git.openjdk.org/valhalla/pull/1438

From qamai at openjdk.org  Tue Apr 22 17:16:52 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 22 Apr 2025 17:16:52 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v4]
In-Reply-To: <btyhSbWjZIvM8hWVo_lRhJfvuOYwlm0vYvniKCuFFb0=.9bca20e3-f537-4dee-828a-515d50a80f80@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
 <btyhSbWjZIvM8hWVo_lRhJfvuOYwlm0vYvniKCuFFb0=.9bca20e3-f537-4dee-828a-515d50a80f80@github.com>
Message-ID: <NpEgugp1EJ2mHPyMX-PeUG7qgdFCFRXu-fP4dDbduh0=.c9f62ede-11d5-42a9-b1d2-9bbfda143691@github.com>

On Tue, 22 Apr 2025 15:47:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'lworld' into declaredfields
>  - small adjustments
>  - no need to pass the fields
>  - move declared_nonstatic_fields to ciInstanceKlass

I have also merged the PR with latest lworld to resolve the merge conflict.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1438#issuecomment-2821977550

From qamai at openjdk.org  Tue Apr 22 17:17:38 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 22 Apr 2025 17:17:38 GMT
Subject: [lworld] RFR: 8354981: [lworld] Atomic flat stores need preceding
 CPUMemBar [v2]
In-Reply-To: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
References: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
Message-ID: <ylm8JuGhbKKqlmu-FZPnx3Qmj_nR0MKe9_CHeAiCsJM=.55064fa4-06ed-458c-8187-9ed48b658da1@github.com>

> Hi,
> 
> Atomic flat stores cover many memory slices. As a result, it needs a preceding CPUMemBar or else it only takes the slice of the first field as its memory input, which is incorrect.
> 
> I don't know how to make a regression test for this. I encounter this crash while working on JDK-8335256. The crash was due to the memory input of the flat store gets split during escape analysis. The compiler then tries looking at the flat stores, which is vastly different from what it expects.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'lworld' into fixatomicstore
 - Atomic flat store needs a preceding barrier

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

Changes: https://git.openjdk.org/valhalla/pull/1437/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1437&range=01
  Stats: 28 lines in 1 file changed: 12 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1437.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1437/head:pull/1437

PR: https://git.openjdk.org/valhalla/pull/1437

From qamai at openjdk.org  Tue Apr 22 17:17:38 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 22 Apr 2025 17:17:38 GMT
Subject: [lworld] RFR: 8354981: [lworld] Atomic flat stores need preceding
 CPUMemBar
In-Reply-To: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
References: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
Message-ID: <Xqle_ECFUqu3kDwPYosl7CJWgd3xnGNjg2tXxV7f05w=.0e4e5f71-cf84-4fc7-9512-43d2675f54c1@github.com>

On Thu, 17 Apr 2025 16:58:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Atomic flat stores cover many memory slices. As a result, it needs a preceding CPUMemBar or else it only takes the slice of the first field as its memory input, which is incorrect.
> 
> I don't know how to make a regression test for this. I encounter this crash while working on JDK-8335256. The crash was due to the memory input of the flat store gets split during escape analysis. The compiler then tries looking at the flat stores, which is vastly different from what it expects.
> 
> Please take a look and leave your reviews, thanks a lot.

Thanks, I have merged the PR with latest lworld

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

PR Comment: https://git.openjdk.org/valhalla/pull/1437#issuecomment-2821976104

From duke at openjdk.org  Tue Apr 22 20:55:59 2025
From: duke at openjdk.org (duke)
Date: Tue, 22 Apr 2025 20:55:59 GMT
Subject: [lworld] Withdrawn: 8349068: [lworld] C2 compilation fails with
 "not enough operands for reexecution"
In-Reply-To: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
References: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
Message-ID: <9Jte0YDQO6jiN0-s7c7fNNgIu3eqB6bowlOy7FZxfNg=.62d5fa55-0be1-4f38-9798-ca2b18259275@github.com>

On Wed, 12 Feb 2025 16:31:02 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue here is that `GraphKit::make_runtime_call` is often used to execute a bytecode. As a result, it expects that it may deoptimize and thus need to reexecute the current bytecode in the interpreter. This is the intention of the `assert`, to verify that we are having enough operands for reexecution of the bytecode. However, in the failing case, `GraphKit::make_runtime_call` is not used to execute the bytecode, but to handle the exceptions thrown by that bytecode. In this case, the bytecode itself has finished executing and must not be reexecuted, we can see that in `Parse::catch_inline_exceptions`:
> 
>     // Oops, need to call into the VM to resolve the klasses at runtime.
>     // Note:  This call must not deoptimize, since it is not a real at this bci!
>     kill_dead_locals();
> 
>     make_runtime_call(RC_NO_LEAF | RC_MUST_THROW,
>                       OptoRuntime::rethrow_Type(),
>                       OptoRuntime::rethrow_stub(),
>                       nullptr, nullptr,
>                       ex_node);
> 
> As a result, reexecution is impossible and we don't need to worry about the operand stack, I propose removing the `assert` as it seems to be the cleanest fix.
> 
> The reason this only fails on `lworld` is because here the execution of `aastore` involves a static Java call, resulting in a potential exception that needs catching.
> 
> Please share your thoughts, thanks a lot.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/valhalla/pull/1363

From thartmann at openjdk.org  Wed Apr 23 12:37:06 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 12:37:06 GMT
Subject: [lworld] RFR: 8354981: [lworld] Atomic flat stores need preceding
 CPUMemBar [v2]
In-Reply-To: <ylm8JuGhbKKqlmu-FZPnx3Qmj_nR0MKe9_CHeAiCsJM=.55064fa4-06ed-458c-8187-9ed48b658da1@github.com>
References: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
 <ylm8JuGhbKKqlmu-FZPnx3Qmj_nR0MKe9_CHeAiCsJM=.55064fa4-06ed-458c-8187-9ed48b658da1@github.com>
Message-ID: <DutzvNLoEG8qNG-7INMUqNlbBOsxFQW_xepKGqlRsdo=.cb06b354-8da3-41ed-97ba-d923b7ada911@github.com>

On Tue, 22 Apr 2025 17:17:38 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Atomic flat stores cover many memory slices. As a result, it needs a preceding CPUMemBar or else it only takes the slice of the first field as its memory input, which is incorrect.
>> 
>> I don't know how to make a regression test for this. I encounter this crash while working on JDK-8335256. The crash was due to the memory input of the flat store gets split during escape analysis. The compiler then tries looking at the flat stores, which is vastly different from what it expects.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'lworld' into fixatomicstore
>  - Atomic flat store needs a preceding barrier

The fix looks good to me and all tests passed. Thanks!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1437#pullrequestreview-2787132113

From thartmann at openjdk.org  Wed Apr 23 12:54:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 12:54:56 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v4]
In-Reply-To: <btyhSbWjZIvM8hWVo_lRhJfvuOYwlm0vYvniKCuFFb0=.9bca20e3-f537-4dee-828a-515d50a80f80@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
 <btyhSbWjZIvM8hWVo_lRhJfvuOYwlm0vYvniKCuFFb0=.9bca20e3-f537-4dee-828a-515d50a80f80@github.com>
Message-ID: <axXCjw0gtwyr8CuGSEqhczFnRuxOA2FNpvt1dhlxMvM=.cf8630ea-e297-42ad-8517-356b8368faac@github.com>

On Tue, 22 Apr 2025 15:47:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'lworld' into declaredfields
>  - small adjustments
>  - no need to pass the fields
>  - move declared_nonstatic_fields to ciInstanceKlass

The fix looks good to me and all tests pass. Thanks!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1438#pullrequestreview-2787192589

From thartmann at openjdk.org  Wed Apr 23 12:54:57 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 12:54:57 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v3]
In-Reply-To: <DFEZzBDoiAIUl9axzXv-n3GHEYgfNJFAahqmOwsR-xk=.1c380f4d-49b7-4ee9-aaa6-142340940041@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
 <uUDQnTHkx_CqBM0PVrsu-_MLrpUKw6rydahkg1LULKU=.c2ad1dcc-5f2b-42df-90af-8c0be946663b@github.com>
 <BooVikzA38B6VxFAS_eXcNQcR3-4T4Xn8W1hbjQ3C8o=.35d4958b-1f34-4b93-8a74-4d0fbd17e657@github.com>
 <DFEZzBDoiAIUl9axzXv-n3GHEYgfNJFAahqmOwsR-xk=.1c380f4d-49b7-4ee9-aaa6-142340940041@github.com>
Message-ID: <hSbNwc6aR48naNJEMFNnh9CioD52hcpFPSncL7XLo4Y=.59bbb0e8-58c7-4d1f-af96-0ede07a91dc1@github.com>

On Tue, 22 Apr 2025 13:12:49 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> As a result, moving it to ciInstanceKlass seems to be a logical move.

Okay, I agree.

> I believe you need @Strict @NullRestricted so that the field is inlined.

Ah yes, of course. I'll give it another try later this week.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1438#issuecomment-2824200409

From thartmann at openjdk.org  Wed Apr 23 12:59:05 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 12:59:05 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>
Message-ID: <eQgzjdJetS4P1lmHxbtMf8WDIUTNWExofPfnOD1fQ6M=.db6bf189-5db2-457e-b972-53d10e45d782@github.com>

On Wed, 9 Apr 2025 06:35:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Note that the objects are still not scalarized due to a bug. When we try to decide if the return will unnecessarily keep the oop of an InlineTypeNode alive, we fail to consider the case that some outputs of the oop are memory barriers.

Should this be added to [JDK-8263010](https://bugs.openjdk.org/browse/JDK-8263010) or should we file a new bug for this?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2824210355

From thartmann at openjdk.org  Wed Apr 23 13:05:12 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 13:05:12 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <iuOwXlXYbBD4kxP5SXmXz0VsHlaBT3e8mm_ypa5jxc0=.93ad9ba9-69eb-43fd-8a7a-335eab7b4405@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <iuOwXlXYbBD4kxP5SXmXz0VsHlaBT3e8mm_ypa5jxc0=.93ad9ba9-69eb-43fd-8a7a-335eab7b4405@github.com>
Message-ID: <oqRbxvMcZmRzsLeNlRloZuR5Ogd6VcJ-IrS7N9jZnBo=.e2c7b890-2115-4d15-abe2-99a852cdc0d9@github.com>

On Tue, 8 Apr 2025 21:48:53 GMT, R?mi Forax <forax at openjdk.org> wrote:

> That's the plan, see
> https://openjdk.org/jeps/8350458

@forax I think @liach was referring to the optimization added by this PR, i.e. upstreaming this particular C2 optimization to mainline once strict field support is there.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2824229566

From thartmann at openjdk.org  Wed Apr 23 13:11:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 13:11:52 GMT
Subject: [lworld] RFR: 8355317: [lworld] C2 Runtime load_unknown_inline should
 not return null-free type
Message-ID: <0xFENiNsQvI5M6hIgOj6LzmcAW2tdRlBNHJ-sl8akZM=.8820863b-06dd-44a1-b867-954d335489ad@github.com>

We incorrectly mark the result of `load_unknown_inline` as null-free which is not correct anymore after [JDK-8341767](https://bugs.openjdk.org/browse/JDK-8341767) because nullable arrays can now be flat as well.

I also noticed that the optimization added by [JDK-8228622](https://bugs.openjdk.org/browse/JDK-8228622) assumes that when we load from an unknown array and then cast the result to a non-value class, we can deduce that the array is not flat if the cast succeeds. That only applies to null-free, flat but not to nullable, flat arrays because null will pass the cast. I filed [JDK-8355382](https://bugs.openjdk.org/browse/JDK-8355382) to follow up on this.

Thanks,
Tobias

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

Commit messages:
 - 8355317: [lworld] C2 Runtime load_unknown_inline should not return null-free type

Changes: https://git.openjdk.org/valhalla/pull/1441/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1441&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355317
  Stats: 60 lines in 5 files changed: 51 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/1441.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1441/head:pull/1441

PR: https://git.openjdk.org/valhalla/pull/1441

From qamai at openjdk.org  Wed Apr 23 13:12:57 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 23 Apr 2025 13:12:57 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v3]
In-Reply-To: <hSbNwc6aR48naNJEMFNnh9CioD52hcpFPSncL7XLo4Y=.59bbb0e8-58c7-4d1f-af96-0ede07a91dc1@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
 <uUDQnTHkx_CqBM0PVrsu-_MLrpUKw6rydahkg1LULKU=.c2ad1dcc-5f2b-42df-90af-8c0be946663b@github.com>
 <BooVikzA38B6VxFAS_eXcNQcR3-4T4Xn8W1hbjQ3C8o=.35d4958b-1f34-4b93-8a74-4d0fbd17e657@github.com>
 <DFEZzBDoiAIUl9axzXv-n3GHEYgfNJFAahqmOwsR-xk=.1c380f4d-49b7-4ee9-aaa6-142340940041@github.com>
 <hSbNwc6aR48naNJEMFNnh9CioD52hcpFPSncL7XLo4Y=.59bbb0e8-58c7-4d1f-af96-0ede07a91dc1@github.com>
Message-ID: <FvOB-pBUuGZz6RJs5-rXBKYjNlO6bDBTX1qhr_ph7rQ=.5102d99f-5d4d-4b59-ae23-a933f6cbe72a@github.com>

On Wed, 23 Apr 2025 12:52:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @TobiHartmann 
>> 
>>> Isn't that sufficient?
>> 
>> It can be. I think, however, it is confusing to have `non_static_fields` referring to different things when a type is a concrete class and when it is an abstract class. I also think that `declared_nonstatic_fields` seems not to be something that is only applicable to value classes. As a result, moving it to `ciInstanceKlass` seems to be a logical move.
>> 
>>> I could also not reproduce [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) (see details in JBS).
>> 
>> I believe you need `@Strict @NullRestricted` so that the field is inlined.
>
>> As a result, moving it to ciInstanceKlass seems to be a logical move.
> 
> Okay, I agree.
> 
>> I believe you need @Strict @NullRestricted so that the field is inlined.
> 
> Ah yes, of course. I'll give it another try later this week.

@TobiHartmann Thanks a lot for your reviews and testing!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1438#issuecomment-2824249483

From duke at openjdk.org  Wed Apr 23 13:12:58 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Apr 2025 13:12:58 GMT
Subject: [lworld] RFR: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation [v4]
In-Reply-To: <btyhSbWjZIvM8hWVo_lRhJfvuOYwlm0vYvniKCuFFb0=.9bca20e3-f537-4dee-828a-515d50a80f80@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
 <btyhSbWjZIvM8hWVo_lRhJfvuOYwlm0vYvniKCuFFb0=.9bca20e3-f537-4dee-828a-515d50a80f80@github.com>
Message-ID: <JlqkHI9MPtCdJAk_pPQ6MSBC5US_iN8EFh7OcGKatCI=.edecaac1-093a-4957-8f60-fc45c8020388@github.com>

On Tue, 22 Apr 2025 15:47:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'lworld' into declaredfields
>  - small adjustments
>  - no need to pass the fields
>  - move declared_nonstatic_fields to ciInstanceKlass

@merykitty 
Your change (at version 7a230fb27d627b206b79bb0ce46f121ff7803368) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1438#issuecomment-2824252358

From qamai at openjdk.org  Wed Apr 23 13:15:00 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 23 Apr 2025 13:15:00 GMT
Subject: [lworld] RFR: 8354981: [lworld] Atomic flat stores need preceding
 CPUMemBar [v2]
In-Reply-To: <DutzvNLoEG8qNG-7INMUqNlbBOsxFQW_xepKGqlRsdo=.cb06b354-8da3-41ed-97ba-d923b7ada911@github.com>
References: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
 <ylm8JuGhbKKqlmu-FZPnx3Qmj_nR0MKe9_CHeAiCsJM=.55064fa4-06ed-458c-8187-9ed48b658da1@github.com>
 <DutzvNLoEG8qNG-7INMUqNlbBOsxFQW_xepKGqlRsdo=.cb06b354-8da3-41ed-97ba-d923b7ada911@github.com>
Message-ID: <HvmfrsC6DvR4d6m_-itaEdShBauTgaKGkCsfxHxq2Y4=.bb8130d4-420f-4e48-8ffe-2d252d2bcb75@github.com>

On Wed, 23 Apr 2025 12:33:49 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'lworld' into fixatomicstore
>>  - Atomic flat store needs a preceding barrier
>
> The fix looks good to me and all tests passed. Thanks!

@TobiHartmann Thanks a lot for the reviews and testing!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1437#issuecomment-2824252782

From duke at openjdk.org  Wed Apr 23 13:15:00 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Apr 2025 13:15:00 GMT
Subject: [lworld] RFR: 8354981: [lworld] Atomic flat stores need preceding
 CPUMemBar [v2]
In-Reply-To: <ylm8JuGhbKKqlmu-FZPnx3Qmj_nR0MKe9_CHeAiCsJM=.55064fa4-06ed-458c-8187-9ed48b658da1@github.com>
References: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
 <ylm8JuGhbKKqlmu-FZPnx3Qmj_nR0MKe9_CHeAiCsJM=.55064fa4-06ed-458c-8187-9ed48b658da1@github.com>
Message-ID: <-9aNC0s08PD4GFOGTKwfEW3K52SdyxrQOKqBoxtmcdI=.5a697c24-23b1-485c-b7d1-4dfaf1d1b790@github.com>

On Tue, 22 Apr 2025 17:17:38 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Atomic flat stores cover many memory slices. As a result, it needs a preceding CPUMemBar or else it only takes the slice of the first field as its memory input, which is incorrect.
>> 
>> I don't know how to make a regression test for this. I encounter this crash while working on JDK-8335256. The crash was due to the memory input of the flat store gets split during escape analysis. The compiler then tries looking at the flat stores, which is vastly different from what it expects.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'lworld' into fixatomicstore
>  - Atomic flat store needs a preceding barrier

@merykitty 
Your change (at version 890ca95177e6d8ef0dc0f1e783483f88b3b77441) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1437#issuecomment-2824258797

From qamai at openjdk.org  Wed Apr 23 13:17:05 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 23 Apr 2025 13:17:05 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <eQgzjdJetS4P1lmHxbtMf8WDIUTNWExofPfnOD1fQ6M=.db6bf189-5db2-457e-b972-53d10e45d782@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>
 <eQgzjdJetS4P1lmHxbtMf8WDIUTNWExofPfnOD1fQ6M=.db6bf189-5db2-457e-b972-53d10e45d782@github.com>
Message-ID: <lcBUDqjunECkW2Y5syrL2JvgTZFwC4IReWECsn8rzVc=.00368874-9fc1-4ca4-81be-2277533a8af6@github.com>

On Wed, 23 Apr 2025 12:55:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Should this be added to [JDK-8263010](https://bugs.openjdk.org/browse/JDK-8263010) or should we file a new bug for this?

Thanks for the pointer, let me take over that issue and investigate it. I will file a new bug if it turns out to be not the same.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2824265515

From qamai at openjdk.org  Wed Apr 23 13:31:52 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 23 Apr 2025 13:31:52 GMT
Subject: [lworld] Integrated: 8355076: [lworld] Incorrect
 declared_nonstatic_fields computation
In-Reply-To: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
References: <IvedZRgoFiBkNahp8n8ULWn8ksNE_x_ebtwtEiLD0cg=.749c2983-e2d5-4652-b7de-ffbf710c9b80@github.com>
Message-ID: <j7FsPybplTLenDnlZcCeGph2kEnk2ci4Z3-yW2DWyJQ=.35851504-074e-47d1-bc26-4c55c276bc23@github.com>

On Sat, 19 Apr 2025 18:39:51 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch fixes the computation of declared_nonstatic_fields if the super class contains flat fields. Note that due to [JDK-8354322](https://bugs.openjdk.org/browse/JDK-8354322) such cases are not present at the moment.
> 
> Please kindly review, thanks a lot.

This pull request has now been integrated.

Changeset: cb47c37c
Author:    Quan Anh Mai <qamai at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cb47c37ca5df9c4c4a3ac9c47785473a6174cdb0
Stats:     245 lines in 4 files changed: 89 ins; 89 del; 67 mod

8355076: [lworld] Incorrect declared_nonstatic_fields computation

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1438

From qamai at openjdk.org  Wed Apr 23 13:31:52 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 23 Apr 2025 13:31:52 GMT
Subject: [lworld] Integrated: 8354981: [lworld] Atomic flat stores need
 preceding CPUMemBar
In-Reply-To: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
References: <8eehiLMgir3nI31sl2gWNs8OSQHpt9vCCKsYkfF34Bo=.f41eacd3-0eba-4917-ac77-6ccd808fe774@github.com>
Message-ID: <HXclcxDWBD0Dcy09Dt_LgNchclGW2C_hm1JDOV2slwY=.a77f375d-21e9-4b04-a524-506740528321@github.com>

On Thu, 17 Apr 2025 16:58:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Atomic flat stores cover many memory slices. As a result, it needs a preceding CPUMemBar or else it only takes the slice of the first field as its memory input, which is incorrect.
> 
> I don't know how to make a regression test for this. I encounter this crash while working on JDK-8335256. The crash was due to the memory input of the flat store gets split during escape analysis. The compiler then tries looking at the flat stores, which is vastly different from what it expects.
> 
> Please take a look and leave your reviews, thanks a lot.

This pull request has now been integrated.

Changeset: 4bd22a85
Author:    Quan Anh Mai <qamai at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4bd22a85b1936aaa89a578f5827510ab062eb169
Stats:     28 lines in 1 file changed: 12 ins; 10 del; 6 mod

8354981: [lworld] Atomic flat stores need preceding CPUMemBar

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1437

From thartmann at openjdk.org  Wed Apr 23 18:15:21 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 18:15:21 GMT
Subject: [lworld] Integrated: 8355317: [lworld] C2 Runtime load_unknown_inline
 should not return null-free type
In-Reply-To: <0xFENiNsQvI5M6hIgOj6LzmcAW2tdRlBNHJ-sl8akZM=.8820863b-06dd-44a1-b867-954d335489ad@github.com>
References: <0xFENiNsQvI5M6hIgOj6LzmcAW2tdRlBNHJ-sl8akZM=.8820863b-06dd-44a1-b867-954d335489ad@github.com>
Message-ID: <oxKZL-dUoY4_urcPxYj_bGVcrgAg0I2P9Y3aYTpS9eU=.ee899b65-eb00-46a3-8059-0f14763c8ae0@github.com>

On Wed, 23 Apr 2025 12:08:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We incorrectly mark the result of `load_unknown_inline` as null-free which is not correct anymore after [JDK-8341767](https://bugs.openjdk.org/browse/JDK-8341767) because nullable arrays can now be flat as well.
> 
> I also noticed that the optimization added by [JDK-8228622](https://bugs.openjdk.org/browse/JDK-8228622) assumes that when we load from an unknown array and then cast the result to a non-value class, we can deduce that the array is not flat if the cast succeeds. That only applies to null-free, flat but not to nullable, flat arrays because null will pass the cast. I filed [JDK-8355382](https://bugs.openjdk.org/browse/JDK-8355382) to follow up on this.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: ad591c50
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ad591c50055e019885dcfc9c98d16c30b4fc9c7e
Stats:     60 lines in 5 files changed: 51 ins; 2 del; 7 mod

8355317: [lworld] C2 Runtime load_unknown_inline should not return null-free type

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

PR: https://git.openjdk.org/valhalla/pull/1441

From thartmann at openjdk.org  Wed Apr 23 19:03:02 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 19:03:02 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
Message-ID: <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>

On Wed, 9 Apr 2025 17:46:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix wrong results
>  - fix invalid node class: Unlock

Testing all passed. I had a first look at the changes and left a few comments. Will have another look tomorrow.

src/hotspot/share/opto/memnode.cpp line 237:

> 235: // current compilation unit, or is the first parameter when we are in a constructor
> 236: static bool call_can_modify_local_object(ciField* field, CallNode* call, Node* base_local) {
> 237:   // The fields can only be modified in this method or in a constructor

Comments and naming of this method are a bit confusing. Isn't this basically checking if `base_local` is the receiver of a constructor call `call`?

src/hotspot/share/opto/memnode.cpp line 238:

> 236: static bool call_can_modify_local_object(ciField* field, CallNode* call, Node* base_local) {
> 237:   // The fields can only be modified in this method or in a constructor
> 238:   if (!call->is_CallJava() || call->req() <= TypeFunc::Parms) {

Isn't it guaranteed for an object constructor to always have `call->req() > TypeFunc::Parms`? So maybe this should be an assert.

src/hotspot/share/opto/memnode.cpp line 248:

> 246: 
> 247:   Node* parm = call->in(TypeFunc::Parms);
> 248:   if (parm->uncast() == base_local || (parm->is_InlineType() && parm->as_InlineType()->get_oop()->uncast() == base_local)) {

There's some code duplication with the checks in `optimize_strict_final_load_memory_from_local_object`, could that be factored out? Especially since the comments there are helpful.

src/hotspot/share/opto/memnode.cpp line 257:

> 255:   assert(t_oop != nullptr, "sanity");
> 256:   bool is_instance = t_oop->is_known_instance_field();
> 257: 

What about the `is_boxed_value_load`? If Valhalla / preview is disabled, these wouldn't be covered by `is_strict_final_load` right?

src/hotspot/share/opto/memnode.cpp line 288:

> 286:     if (tmp != nullptr) {
> 287:       result = tmp;
> 288:     }

Suggestion:

    result = optimize_strict_final_load_memory(phase, field, adr, base_local);
    if (result == nullptr) {
      result = mchain;
    }

src/hotspot/share/opto/memnode.cpp line 330:

> 328:             // Allocation of another type, must be another object
> 329:             result = proj_in->in(TypeFunc::Memory);
> 330:           } else if (base_local != nullptr && (base_local->is_Parm() || base_local->in(0) != alloc)) {

Should this be changed to `base_local->as_Proj()->in(0)` to assert that `base_local` is a projection?

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

PR Review: https://git.openjdk.org/valhalla/pull/1424#pullrequestreview-2787272535
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2056679081
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2056278539
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2056714221
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2056031664
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2056231927
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2056228558

From thartmann at openjdk.org  Wed Apr 23 19:03:03 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 19:03:03 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <lcBUDqjunECkW2Y5syrL2JvgTZFwC4IReWECsn8rzVc=.00368874-9fc1-4ca4-81be-2277533a8af6@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>
 <eQgzjdJetS4P1lmHxbtMf8WDIUTNWExofPfnOD1fQ6M=.db6bf189-5db2-457e-b972-53d10e45d782@github.com>
 <lcBUDqjunECkW2Y5syrL2JvgTZFwC4IReWECsn8rzVc=.00368874-9fc1-4ca4-81be-2277533a8af6@github.com>
Message-ID: <iYesGvSH1AS2FJvd0uOTKiKqpLBOIhq_UgUZt1-C5Xo=.70c8ba73-8a5c-4c7d-b976-09bf5ad8c1c3@github.com>

On Wed, 23 Apr 2025 13:14:17 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Thanks for the pointer, let me take over that issue and investigate it. I will file a new bug if it turns out to be not the same.

Thank you so much!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2825241962

From thartmann at openjdk.org  Wed Apr 23 19:03:03 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Apr 2025 19:03:03 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
 <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
Message-ID: <tTcnLtOvhaJFmR7f2Kqh11Fm-N7xlcGTAwR1Myn2NIw=.93e58bc0-5fb7-423f-b767-d9b8bf4ed089@github.com>

On Wed, 23 Apr 2025 13:15:17 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix wrong results
>>  - fix invalid node class: Unlock
>
> src/hotspot/share/opto/memnode.cpp line 257:
> 
>> 255:   assert(t_oop != nullptr, "sanity");
>> 256:   bool is_instance = t_oop->is_known_instance_field();
>> 257: 
> 
> What about the `is_boxed_value_load`? If Valhalla / preview is disabled, these wouldn't be covered by `is_strict_final_load` right?

I also wonder if the other usages of `is_ptr_to_boxed_value()` in the code could need some update.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2056213104

From qamai at openjdk.org  Thu Apr 24 01:19:45 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 01:19:45 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v3]
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <m-vYGdMQEn6-hyKvtEyIhDuoAOtaCWFkm5LGPCECDBE=.715a5aa8-4724-4512-bd75-50fb382d6a02@github.com>

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai 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 seven additional commits since the last revision:

 - must find a field
 - Tobias comments
 - Merge branch 'lworld' into strictload
 - fix wrong results
 - fix invalid node class: Unlock
 - add tests
 - fold strict final field loads

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1424/files
  - new: https://git.openjdk.org/valhalla/pull/1424/files/b2601380..b5dd90b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=01-02

  Stats: 93635 lines in 2607 files changed: 35915 ins; 46769 del; 10951 mod
  Patch: https://git.openjdk.org/valhalla/pull/1424.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1424/head:pull/1424

PR: https://git.openjdk.org/valhalla/pull/1424

From qamai at openjdk.org  Thu Apr 24 01:19:46 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 01:19:46 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <iYesGvSH1AS2FJvd0uOTKiKqpLBOIhq_UgUZt1-C5Xo=.70c8ba73-8a5c-4c7d-b976-09bf5ad8c1c3@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <tQATWKjsuozwG-3TY8TYoHe0-OWhPp4ihoEp3bzzA0A=.6620a5c6-18d4-4a54-97eb-476b35328964@github.com>
 <eQgzjdJetS4P1lmHxbtMf8WDIUTNWExofPfnOD1fQ6M=.db6bf189-5db2-457e-b972-53d10e45d782@github.com>
 <lcBUDqjunECkW2Y5syrL2JvgTZFwC4IReWECsn8rzVc=.00368874-9fc1-4ca4-81be-2277533a8af6@github.com>
 <iYesGvSH1AS2FJvd0uOTKiKqpLBOIhq_UgUZt1-C5Xo=.70c8ba73-8a5c-4c7d-b976-09bf5ad8c1c3@github.com>
Message-ID: <VNYdjbblRwmn5T2G6F2DIFJ7Z-9m_-tTl3h9aR1g8rA=.9bb9baf5-87fd-4cf1-a348-ee73a382fbb1@github.com>

On Wed, 23 Apr 2025 18:58:29 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>>> Should this be added to [JDK-8263010](https://bugs.openjdk.org/browse/JDK-8263010) or should we file a new bug for this?
>> 
>> Thanks for the pointer, let me take over that issue and investigate it. I will file a new bug if it turns out to be not the same.
>
>> Thanks for the pointer, let me take over that issue and investigate it. I will file a new bug if it turns out to be not the same.
> 
> Thank you so much!

@TobiHartmann Thanks a lot for your reviews, I have addressed them.

> I also wonder if the other usages of `is_ptr_to_boxed_value()` in the code could need some update.

That's reasonable, we can generalize this method to other value class fields.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2825911943

From qamai at openjdk.org  Thu Apr 24 01:19:48 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 01:19:48 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
 <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
Message-ID: <KzCJdTMRXebxRyKac-pLkyuM5Z9ekRMSuVoFg7g3f2g=.a6f805b6-1b05-4919-ae5e-9ebdeccd24ef@github.com>

On Wed, 23 Apr 2025 18:35:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix wrong results
>>  - fix invalid node class: Unlock
>
> src/hotspot/share/opto/memnode.cpp line 237:
> 
>> 235: // current compilation unit, or is the first parameter when we are in a constructor
>> 236: static bool call_can_modify_local_object(ciField* field, CallNode* call, Node* base_local) {
>> 237:   // The fields can only be modified in this method or in a constructor
> 
> Comments and naming of this method are a bit confusing. Isn't this basically checking if `base_local` is the receiver of a constructor call `call`?

Yes the comment should refer to `base_local` not `base`. I have also added a section clarifying that this method is equivalent to asking whether `base_local` is the receiver of a constructor call `call` and the holder of `call` is a subclass of the holder of `field`.

> src/hotspot/share/opto/memnode.cpp line 248:
> 
>> 246: 
>> 247:   Node* parm = call->in(TypeFunc::Parms);
>> 248:   if (parm->uncast() == base_local || (parm->is_InlineType() && parm->as_InlineType()->get_oop()->uncast() == base_local)) {
> 
> There's some code duplication with the checks in `optimize_strict_final_load_memory_from_local_object`, could that be factored out? Especially since the comments there are helpful.

Done so in the new commit

> src/hotspot/share/opto/memnode.cpp line 288:
> 
>> 286:     if (tmp != nullptr) {
>> 287:       result = tmp;
>> 288:     }
> 
> Suggestion:
> 
>     result = optimize_strict_final_load_memory(phase, field, adr, base_local);
>     if (result == nullptr) {
>       result = mchain;
>     }

I find it easier to say that this method tries to find a memory node and if it succeeds we set `result` to the found node.

> src/hotspot/share/opto/memnode.cpp line 330:
> 
>> 328:             // Allocation of another type, must be another object
>> 329:             result = proj_in->in(TypeFunc::Memory);
>> 330:           } else if (base_local != nullptr && (base_local->is_Parm() || base_local->in(0) != alloc)) {
> 
> Should this be changed to `base_local->as_Proj()->in(0)` to assert that `base_local` is a projection?

I have refactored `base_local` to be a `ProjNode*` to make this more explicit.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2057151605
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2057150487
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2057152806
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2057144999

From qamai at openjdk.org  Thu Apr 24 01:19:48 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 01:19:48 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <tTcnLtOvhaJFmR7f2Kqh11Fm-N7xlcGTAwR1Myn2NIw=.93e58bc0-5fb7-423f-b767-d9b8bf4ed089@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
 <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
 <tTcnLtOvhaJFmR7f2Kqh11Fm-N7xlcGTAwR1Myn2NIw=.93e58bc0-5fb7-423f-b767-d9b8bf4ed089@github.com>
Message-ID: <I-aw4M2pbFTLnYnEGm5l9-AB5u15oP4aNLk_jBrkH1E=.60a079e4-b5cb-495e-91c7-299dad316bb6@github.com>

On Wed, 23 Apr 2025 14:36:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/opto/memnode.cpp line 257:
>> 
>>> 255:   assert(t_oop != nullptr, "sanity");
>>> 256:   bool is_instance = t_oop->is_known_instance_field();
>>> 257: 
>> 
>> What about the `is_boxed_value_load`? If Valhalla / preview is disabled, these wouldn't be covered by `is_strict_final_load` right?
>
> I also wonder if the other usages of `is_ptr_to_boxed_value()` in the code could need some update.

That's right, I have added a case when valhalla is not enabled to catch `is_ptr_to_boxed_value` then.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2057149416

From qamai at openjdk.org  Thu Apr 24 01:35:33 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 01:35:33 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v4]
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <ZIdCV_HbtYqyLyjERT4y7NJrOc2uBK7GfBG64Wr-syM=.2c02436c-0b01-4a86-85df-1a8869d34209@github.com>

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix non-valhalla

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1424/files
  - new: https://git.openjdk.org/valhalla/pull/1424/files/b5dd90b2..b12ba710

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1424.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1424/head:pull/1424

PR: https://git.openjdk.org/valhalla/pull/1424

From thartmann at openjdk.org  Thu Apr 24 13:22:16 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Apr 2025 13:22:16 GMT
Subject: [lworld] Integrated: 8355299: [lworld] C2 compilation fails with
 "unexpected yanked node"
Message-ID: <Q1dl1JpgQj9MOANuRND31Zf-qCVNZo-z0zAyZu8ld_k=.80c7ac2a-d03a-40ed-99d0-d7806c04a9f9@github.com>

We hit an assert in the register allocator because a `DecodeN` is kept alive by a `MemBarVolatile`:

o183 ConvL2I === _ o182 [[ o184 ]] #int
o184 CastI2N === o179 o183 [[ o419 ]]
o419 DecodeN === _ o184 [[ o187 65 ]] #float[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact *
o187 MemBarVolatile === o179 o1 o180 o1 o1 o419 [[ o188 o189 64 ]]
 65 membar_volatile === 67 0 94 0 0 o419 [[ 66 ]] !jvms: TestGenerated::test11 @ bci:2 (line 201)


The membar is emitted by `InlineTypeNode::convert_from_payload` to prevent a `CastI2N` from floating below a safepoint. This is necessary to avoid having the raw pointer span a safepoint, making it opaque to the GC.

On second thought, I don't think we need a membar to prevent this from happening. I removed it and added a comment explaining the details. All tests, including our stress testing, still pass.

Thanks,
Tobias

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

Commit messages:
 - 8355299: [lworld] C2 compilation fails with "unexpected yanked node"

Changes: https://git.openjdk.org/valhalla/pull/1442/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1442&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355299
  Stats: 9 lines in 2 files changed: 5 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1442.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1442/head:pull/1442

PR: https://git.openjdk.org/valhalla/pull/1442

From thartmann at openjdk.org  Thu Apr 24 13:22:16 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Apr 2025 13:22:16 GMT
Subject: [lworld] Integrated: 8355299: [lworld] C2 compilation fails with
 "unexpected yanked node"
In-Reply-To: <Q1dl1JpgQj9MOANuRND31Zf-qCVNZo-z0zAyZu8ld_k=.80c7ac2a-d03a-40ed-99d0-d7806c04a9f9@github.com>
References: <Q1dl1JpgQj9MOANuRND31Zf-qCVNZo-z0zAyZu8ld_k=.80c7ac2a-d03a-40ed-99d0-d7806c04a9f9@github.com>
Message-ID: <xLqBn4YJfdEgEI1bqwB-y7_K2v9PV8VHhd2M865HSnA=.fe9c3f9f-34f8-402d-be10-52b1ea2eb3b1@github.com>

On Thu, 24 Apr 2025 13:15:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit an assert in the register allocator because a `DecodeN` is kept alive by a `MemBarVolatile`:
> 
> o183 ConvL2I === _ o182 [[ o184 ]] #int
> o184 CastI2N === o179 o183 [[ o419 ]]
> o419 DecodeN === _ o184 [[ o187 65 ]] #float[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact *
> o187 MemBarVolatile === o179 o1 o180 o1 o1 o419 [[ o188 o189 64 ]]
>  65 membar_volatile === 67 0 94 0 0 o419 [[ 66 ]] !jvms: TestGenerated::test11 @ bci:2 (line 201)
> 
> 
> The membar is emitted by `InlineTypeNode::convert_from_payload` to prevent a `CastI2N` from floating below a safepoint. This is necessary to avoid having the raw pointer span a safepoint, making it opaque to the GC.
> 
> On second thought, I don't think we need a membar to prevent this from happening. I removed it and added a comment explaining the details. All tests, including our stress testing, still pass.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: e1280b3e
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e1280b3e11a98d98c0fdad73ce9c8bb9d2417a70
Stats:     9 lines in 2 files changed: 5 ins; 1 del; 3 mod

8355299: [lworld] C2 compilation fails with "unexpected yanked node"

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

PR: https://git.openjdk.org/valhalla/pull/1442

From thartmann at openjdk.org  Thu Apr 24 14:01:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Apr 2025 14:01:18 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v4]
In-Reply-To: <ZIdCV_HbtYqyLyjERT4y7NJrOc2uBK7GfBG64Wr-syM=.2c02436c-0b01-4a86-85df-1a8869d34209@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <ZIdCV_HbtYqyLyjERT4y7NJrOc2uBK7GfBG64Wr-syM=.2c02436c-0b01-4a86-85df-1a8869d34209@github.com>
Message-ID: <0lq4bwocIxb0tcvzZgX6-O0hobeDM_ooyFyvFAf_bfU=.db20f106-9351-4820-a015-bce3851679b2@github.com>

On Thu, 24 Apr 2025 01:35:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix non-valhalla

Not sure how I can mark a conversation as unresolved again, so also posting this here:
> But what I mean is that before your changes, we also executed this code if t_oop->is_ptr_to_boxed_value() was true but now we bail out. And if EnableValhalla is false, and primitive boxes are not value classes, we would therefore not optimize loads from those boxes anymore, right?

src/hotspot/share/opto/memnode.cpp line 152:

> 150: // constructor invocation. E.g. A field Super.x will be set during the execution of Sub::<init>,
> 151: // while a field Sub.y must be set before Super::<init> is invoked.
> 152: static ciInstanceKlass* find_constructor_call_method_holder(Node* n, Node* receiver) {

Suggestion:

static ciInstanceKlass* find_constructor_call_method_holder(Node* call, Node* receiver) {

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2827727443
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2058461336

From thartmann at openjdk.org  Thu Apr 24 14:01:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Apr 2025 14:01:18 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <KzCJdTMRXebxRyKac-pLkyuM5Z9ekRMSuVoFg7g3f2g=.a6f805b6-1b05-4919-ae5e-9ebdeccd24ef@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
 <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
 <KzCJdTMRXebxRyKac-pLkyuM5Z9ekRMSuVoFg7g3f2g=.a6f805b6-1b05-4919-ae5e-9ebdeccd24ef@github.com>
Message-ID: <LaO58zbEcB0nMGUa4gcOgCXGo72-LxR3qGmggpA3dU4=.81a83bdb-d0ac-4a3e-bbb1-b0fc09edbaa3@github.com>

On Thu, 24 Apr 2025 01:13:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/memnode.cpp line 237:
>> 
>>> 235: // current compilation unit, or is the first parameter when we are in a constructor
>>> 236: static bool call_can_modify_local_object(ciField* field, CallNode* call, Node* base_local) {
>>> 237:   // The fields can only be modified in this method or in a constructor
>> 
>> Comments and naming of this method are a bit confusing. Isn't this basically checking if `base_local` is the receiver of a constructor call `call`?
>
> Yes the comment should refer to `base_local` not `base`. I have also added a section clarifying that this method is equivalent to asking whether `base_local` is the receiver of a constructor call `call` and the holder of `call` is a subclass of the holder of `field`.

Looks good, thanks for updating.

>> src/hotspot/share/opto/memnode.cpp line 288:
>> 
>>> 286:     if (tmp != nullptr) {
>>> 287:       result = tmp;
>>> 288:     }
>> 
>> Suggestion:
>> 
>>     result = optimize_strict_final_load_memory(phase, field, adr, base_local);
>>     if (result == nullptr) {
>>       result = mchain;
>>     }
>
> I find it easier to say that this method tries to find a memory node and if it succeeds we set `result` to the found node.

Okay, fine with me.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2058518459
PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2058518828

From thartmann at openjdk.org  Thu Apr 24 14:01:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Apr 2025 14:01:18 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <I-aw4M2pbFTLnYnEGm5l9-AB5u15oP4aNLk_jBrkH1E=.60a079e4-b5cb-495e-91c7-299dad316bb6@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
 <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
 <tTcnLtOvhaJFmR7f2Kqh11Fm-N7xlcGTAwR1Myn2NIw=.93e58bc0-5fb7-423f-b767-d9b8bf4ed089@github.com>
 <I-aw4M2pbFTLnYnEGm5l9-AB5u15oP4aNLk_jBrkH1E=.60a079e4-b5cb-495e-91c7-299dad316bb6@github.com>
Message-ID: <JyTSNgKqhEzyr_waOOrgP1bNYEY1Y-lXgKKnhVlirsw=.c77905c5-8e24-40c3-8d6d-9ec67e196640@github.com>

On Thu, 24 Apr 2025 01:12:10 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> I also wonder if the other usages of `is_ptr_to_boxed_value()` in the code could need some update.
>
> That's right, I have added a case when valhalla is not enabled to catch `is_ptr_to_boxed_value` then.

But what I mean is that before your changes, we also executed this code if `t_oop->is_ptr_to_boxed_value()` was true but now we bail out. And if EnableValhalla is false, and primitive boxes are not value classes, we would therefore not optimize loads from those boxes anymore, right?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2058472106

From qamai at openjdk.org  Thu Apr 24 14:28:45 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 14:28:45 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v5]
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <H_lOa-UQmNmIV5BaEeuwvAFt9sCalODT1RfUuBmyfYo=.af1b3652-b890-4dc3-9f5b-479abddc0231@github.com>

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  rename n to call

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1424/files
  - new: https://git.openjdk.org/valhalla/pull/1424/files/b12ba710..38384c57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=04
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=03-04

  Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1424.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1424/head:pull/1424

PR: https://git.openjdk.org/valhalla/pull/1424

From qamai at openjdk.org  Thu Apr 24 14:28:50 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 14:28:50 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v4]
In-Reply-To: <0lq4bwocIxb0tcvzZgX6-O0hobeDM_ooyFyvFAf_bfU=.db20f106-9351-4820-a015-bce3851679b2@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <ZIdCV_HbtYqyLyjERT4y7NJrOc2uBK7GfBG64Wr-syM=.2c02436c-0b01-4a86-85df-1a8869d34209@github.com>
 <0lq4bwocIxb0tcvzZgX6-O0hobeDM_ooyFyvFAf_bfU=.db20f106-9351-4820-a015-bce3851679b2@github.com>
Message-ID: <jeuzM7wwtFELLvjSBAPCrkSNft-U2AgPM0Jpjr_6XxE=.2a3da580-6187-47d2-a024-311bde58c283@github.com>

On Thu, 24 Apr 2025 13:32:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix non-valhalla
>
> src/hotspot/share/opto/memnode.cpp line 152:
> 
>> 150: // constructor invocation. E.g. A field Super.x will be set during the execution of Sub::<init>,
>> 151: // while a field Sub.y must be set before Super::<init> is invoked.
>> 152: static ciInstanceKlass* find_constructor_call_method_holder(Node* n, Node* receiver) {
> 
> Suggestion:
> 
> static ciInstanceKlass* find_constructor_call_method_holder(Node* call, Node* receiver) {

Done!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2058580869

From qamai at openjdk.org  Thu Apr 24 14:28:52 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 14:28:52 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <JyTSNgKqhEzyr_waOOrgP1bNYEY1Y-lXgKKnhVlirsw=.c77905c5-8e24-40c3-8d6d-9ec67e196640@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
 <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
 <tTcnLtOvhaJFmR7f2Kqh11Fm-N7xlcGTAwR1Myn2NIw=.93e58bc0-5fb7-423f-b767-d9b8bf4ed089@github.com>
 <I-aw4M2pbFTLnYnEGm5l9-AB5u15oP4aNLk_jBrkH1E=.60a079e4-b5cb-495e-91c7-299dad316bb6@github.com>
 <JyTSNgKqhEzyr_waOOrgP1bNYEY1Y-lXgKKnhVlirsw=.c77905c5-8e24-40c3-8d6d-9ec67e196640@github.com>
Message-ID: <1fHfFYaOvVk_kBA0ttQim0GPBu3HzWxYf89E0_e7ec0=.732fe24a-1bad-4abb-9f0a-99bf8cf60f89@github.com>

On Thu, 24 Apr 2025 13:37:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> That's right, I have added a case when valhalla is not enabled to catch `is_ptr_to_boxed_value` then.
>
> But what I mean is that before your changes, we also executed this code if `t_oop->is_ptr_to_boxed_value()` was true but now we bail out. And if EnableValhalla is false, and primitive boxes are not value classes, we would therefore not optimize loads from those boxes anymore, right?

In my latest commit, I mark `is_strict_final_load` as `true` if `t_oop->is_ptr_to_boxed_value()` is `true` when `EnableValhalla` is `false`. Is it what you want, or I am missing something here?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2058580109

From qamai at openjdk.org  Thu Apr 24 14:31:33 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Apr 2025 14:31:33 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v6]
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  identation

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1424/files
  - new: https://git.openjdk.org/valhalla/pull/1424/files/38384c57..978b78c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=05
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1424&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1424.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1424/head:pull/1424

PR: https://git.openjdk.org/valhalla/pull/1424

From thartmann at openjdk.org  Thu Apr 24 14:46:55 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Apr 2025 14:46:55 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v6]
In-Reply-To: <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
Message-ID: <OV6xdxnDW3aIqg2wQtz606F9YpxELD-Rv0p35vyLC9Y=.ea6bb24e-65a7-4748-8cd7-aa62b4b9ed5e@github.com>

On Thu, 24 Apr 2025 14:31:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   identation

Thanks for making these changes, looks good to me. I'll run a last round of testing.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2827906297

From thartmann at openjdk.org  Thu Apr 24 14:46:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Apr 2025 14:46:56 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v2]
In-Reply-To: <1fHfFYaOvVk_kBA0ttQim0GPBu3HzWxYf89E0_e7ec0=.732fe24a-1bad-4abb-9f0a-99bf8cf60f89@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <q3lefbPBHptfTKoowtKKNLMWcaRSUvs4xj4ZexWb3ps=.e07f3be6-41e4-4cfd-9973-44d970215fb7@github.com>
 <2hbUzilYxekdR-aB3G6yitTO_NmNZ74Cku1HteSKixs=.7d0ccaa7-4d09-4e19-a286-973895f0eccc@github.com>
 <tTcnLtOvhaJFmR7f2Kqh11Fm-N7xlcGTAwR1Myn2NIw=.93e58bc0-5fb7-423f-b767-d9b8bf4ed089@github.com>
 <I-aw4M2pbFTLnYnEGm5l9-AB5u15oP4aNLk_jBrkH1E=.60a079e4-b5cb-495e-91c7-299dad316bb6@github.com>
 <JyTSNgKqhEzyr_waOOrgP1bNYEY1Y-lXgKKnhVlirsw=.c77905c5-8e24-40c3-8d6d-9ec67e196640@github.com>
 <1fHfFYaOvVk_kBA0ttQim0GPBu3HzWxYf89E0_e7ec0=.732fe24a-1bad-4abb-9f0a-99bf8cf60f89@github.com>
Message-ID: <49e7nVhPC7PwSYABppzXuu0Ekxh3aQoBYgwrB1FeZH8=.8df9da54-1e0f-4a53-ae9d-b635f2698a01@github.com>

On Thu, 24 Apr 2025 14:25:10 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> But what I mean is that before your changes, we also executed this code if `t_oop->is_ptr_to_boxed_value()` was true but now we bail out. And if EnableValhalla is false, and primitive boxes are not value classes, we would therefore not optimize loads from those boxes anymore, right?
>
> In my latest commit, I mark `is_strict_final_load` as `true` if `t_oop->is_ptr_to_boxed_value()` is `true` when `EnableValhalla` is `false`. Is it what you want, or I am missing something here?

Ah yes, I missed that. Looks good.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1424#discussion_r2058620806

From amenkov at openjdk.org  Fri Apr 25 00:45:19 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 25 Apr 2025 00:45:19 GMT
Subject: [lworld] RFR: 8355560: SetTag/GetTag should consider equal value
 objects as the same object
Message-ID: <xjKQpaZAtF9qPkObbXsXl4CoQyqIHSD3kHmiW83Hxvs=.7d223682-6d63-4fd8-a4de-bd68277bad40@github.com>

Fixes SetTag/GetTag JVMTI functions so they consider equal value object as a single object.

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/valhalla/pull/1444/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355560
  Stats: 331 lines in 4 files changed: 313 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1444.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1444/head:pull/1444

PR: https://git.openjdk.org/valhalla/pull/1444

From thartmann at openjdk.org  Fri Apr 25 06:34:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Apr 2025 06:34:18 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v6]
In-Reply-To: <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
Message-ID: <wJ9tg_Ep1p26_7suicrt6Uzkq9dOaW0bPZsMvBYEXsU=.4a4b38e3-7818-47fb-9a82-4cbba4f7e715@github.com>

On Thu, 24 Apr 2025 14:31:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   identation

All tests passed.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1424#pullrequestreview-2793121017

From thartmann at openjdk.org  Fri Apr 25 10:46:46 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Apr 2025 10:46:46 GMT
Subject: [lworld] RFR: 8354322: [lworld] InlineKlass::collect_fields fails to
 look up flat fields declared in abstract super class
Message-ID: <C2jy-wGJ90L5peEIiN2mZYoKXXsFyCDb_Hsq8ZnL9pM=.888fd006-8a41-462f-912a-bd5eab59d4b3@github.com>

The problem is that we are doing the lookup for a flat field declared in an abstract super class in the subclass and don't find it there.

Thanks,
Tobias

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

Commit messages:
 - Removed imports
 - 8354322: [lworld] InlineKlass::collect_fields fails to look up flat fields declared in abstract super class

Changes: https://git.openjdk.org/valhalla/pull/1445/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1445&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354322
  Stats: 52 lines in 2 files changed: 49 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1445.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1445/head:pull/1445

PR: https://git.openjdk.org/valhalla/pull/1445

From qamai at openjdk.org  Fri Apr 25 10:53:03 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 25 Apr 2025 10:53:03 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v6]
In-Reply-To: <OV6xdxnDW3aIqg2wQtz606F9YpxELD-Rv0p35vyLC9Y=.ea6bb24e-65a7-4748-8cd7-aa62b4b9ed5e@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
 <OV6xdxnDW3aIqg2wQtz606F9YpxELD-Rv0p35vyLC9Y=.ea6bb24e-65a7-4748-8cd7-aa62b4b9ed5e@github.com>
Message-ID: <oWocYU4MyNx1VhajUKho5fyYblh95hH3bDHlEhPpVtU=.6a225cdf-69ae-4c69-b106-76a25ee121e2@github.com>

On Thu, 24 Apr 2025 14:44:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   identation
>
> Thanks for making these changes, looks good to me. I'll run a last round of testing.

@TobiHartmann Thanks a lot for your reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2830076200

From duke at openjdk.org  Fri Apr 25 10:53:03 2025
From: duke at openjdk.org (duke)
Date: Fri, 25 Apr 2025 10:53:03 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v6]
In-Reply-To: <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
Message-ID: <5xaN0hewDYjMRtip7QwiitufmrKAgDOIOUu6XXk71Vo=.30809109-4c0a-468c-be18-052e6077cb49@github.com>

On Thu, 24 Apr 2025 14:31:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   identation

@merykitty 
Your change (at version 978b78c27a5d313e6a9d5f5475c64c8a5f19026e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2830078989

From thartmann at openjdk.org  Fri Apr 25 12:31:59 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Apr 2025 12:31:59 GMT
Subject: [lworld] Integrated: 8354322: [lworld] InlineKlass::collect_fields
 fails to look up flat fields declared in abstract super class
In-Reply-To: <C2jy-wGJ90L5peEIiN2mZYoKXXsFyCDb_Hsq8ZnL9pM=.888fd006-8a41-462f-912a-bd5eab59d4b3@github.com>
References: <C2jy-wGJ90L5peEIiN2mZYoKXXsFyCDb_Hsq8ZnL9pM=.888fd006-8a41-462f-912a-bd5eab59d4b3@github.com>
Message-ID: <JnrfBfdDxF63p8g_xtD8yUV7czY0edgGgqi8dKTwM_g=.dc98c0e2-a029-4402-8b4c-e022ae2ecb55@github.com>

On Fri, 25 Apr 2025 10:41:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The problem is that we are doing the lookup for a flat field declared in an abstract super class in the subclass and don't find it there.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 4825d5f6
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4825d5f64da275866604532ea9b400c872356f1c
Stats:     52 lines in 2 files changed: 49 ins; 0 del; 3 mod

8354322: [lworld] InlineKlass::collect_fields fails to look up flat fields declared in abstract super class

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

PR: https://git.openjdk.org/valhalla/pull/1445

From qamai at openjdk.org  Fri Apr 25 14:56:10 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 25 Apr 2025 14:56:10 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v6]
In-Reply-To: <OV6xdxnDW3aIqg2wQtz606F9YpxELD-Rv0p35vyLC9Y=.ea6bb24e-65a7-4748-8cd7-aa62b4b9ed5e@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
 <OV6xdxnDW3aIqg2wQtz606F9YpxELD-Rv0p35vyLC9Y=.ea6bb24e-65a7-4748-8cd7-aa62b4b9ed5e@github.com>
Message-ID: <ZY7wJxnfPqSpdRnKRE8s9jCULYHoATNslCWkXYZnQGQ=.92c4133e-6c2c-4b87-822f-29812db74d14@github.com>

On Thu, 24 Apr 2025 14:44:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   identation
>
> Thanks for making these changes, looks good to me. I'll run a last round of testing.

@TobiHartmann Can you help me sponsor this change, please?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2830657637

From sspitsyn at openjdk.org  Fri Apr 25 19:40:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 25 Apr 2025 19:40:04 GMT
Subject: [lworld] RFR: 8355560: SetTag/GetTag should consider equal value
 objects as the same object
In-Reply-To: <xjKQpaZAtF9qPkObbXsXl4CoQyqIHSD3kHmiW83Hxvs=.7d223682-6d63-4fd8-a4de-bd68277bad40@github.com>
References: <xjKQpaZAtF9qPkObbXsXl4CoQyqIHSD3kHmiW83Hxvs=.7d223682-6d63-4fd8-a4de-bd68277bad40@github.com>
Message-ID: <C39Hu_mk7qPTlpWrLnyCOG8zYTdVNnqBGpI4C07lnX8=.371bc38f-6a8c-40ba-b0da-abc1f81e0c8c@github.com>

On Fri, 25 Apr 2025 00:39:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Fixes SetTag/GetTag JVMTI functions so they consider equal value object as a single object.

src/hotspot/share/prims/jvmtiTagMapTable.cpp line 142:

> 140: }
> 141: 
> 142: static bool equals_oops(oop obj1, oop obj2) {

Nit: Please, consider to rename functions `equals_value_objects` and `equals_oops` to `equal_value_objects` and `equal_oops`

src/hotspot/share/prims/jvmtiTagMapTable.cpp line 148:

> 146: 
> 147:   if (EnableValhalla) {
> 148:     if (obj1 != nullptr && obj2 != nullptr && obj1->klass() == obj2->klass() && obj1->klass()->is_inline_klass()) {

Nit: I guess, the function `is_inline_type()` can be used instead of `klass()->is_inline_klass()`.

src/hotspot/share/prims/jvmtiTagMapTable.cpp line 153:

> 151:     }
> 152:   }
> 153:   return true;

It looks like we have to return `false` here.

src/hotspot/share/prims/jvmtiTagMapTable.cpp line 162:

> 160:     return equals_oops(lhs_obj, rhs_obj);
> 161:   }
> 162: 

Nit: The checks at line 159 are not really needed as `equals_oops()` provides the same checks.

src/hotspot/share/prims/jvmtiTagMapTable.hpp line 45:

> 43: //
> 44: // Valhalla: tags for equal ("the same") value object are the same.
> 45: // We have to keep strong reference to each unique value object with non-0 tag.

Nit: A suggestion to slightly change the comment lines above:

  // Valhalla: Keep just one tag for all equal value objects including heap allocated value objects.
  // We have to keep a strong reference to each unique value object with a non-zero tag.

src/hotspot/share/prims/jvmtiTagMapTable.hpp line 48:

> 46: class JvmtiTagMapKey : public CHeapObj<mtServiceability> {
> 47:   // All equal value objects should have the same tag.
> 48:   // So have to keep alive value objects (1 copy for each "value") until their tags are removed.

Nit: A suggestion to slightly modify the comment:

  // Keep value objects alive (1 copy for each "value") until their tags are removed.

test/hotspot/jtreg/serviceability/jvmti/valhalla/SetTag/ValueTagMapTest.java line 46:

> 44: 
> 45:     private static value class ValueClass {
> 46:         public int f1;

Nit: It would be better to have different field name with ValueHolder, e.g. f0. Any other name would also work.

test/hotspot/jtreg/serviceability/jvmti/valhalla/SetTag/libValueTagMapTest.cpp line 40:

> 38: }
> 39: 
> 40: }

Nit: The test library functions `check_jvmti_error()` or `check_jvmti_status()` from `jvmti_common.hpp` can be used instead.
Will need to add this line:

#include "jvmti_common.hpp"

test/hotspot/jtreg/serviceability/jvmti/valhalla/SetTag/libValueTagMapTest.cpp line 57:

> 55:     printf("Could not initialize JVMTI\n");
> 56:     fflush(nullptr);
> 57:     abort();

Nit: The test library macro `LOG()` from `jvmti_common.hpp` can be used. It also calls `fflush()`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060792568
PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060788476
PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060785400
PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060790750
PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060730084
PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060737935
PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060711636
PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060718326
PR Review Comment: https://git.openjdk.org/valhalla/pull/1444#discussion_r2060718953

From amenkov at openjdk.org  Sat Apr 26 01:52:03 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 26 Apr 2025 01:52:03 GMT
Subject: [lworld] RFR: 8355560: SetTag/GetTag should consider equal value
 objects as the same object [v2]
In-Reply-To: <xjKQpaZAtF9qPkObbXsXl4CoQyqIHSD3kHmiW83Hxvs=.7d223682-6d63-4fd8-a4de-bd68277bad40@github.com>
References: <xjKQpaZAtF9qPkObbXsXl4CoQyqIHSD3kHmiW83Hxvs=.7d223682-6d63-4fd8-a4de-bd68277bad40@github.com>
Message-ID: <BH71wttbdjH_gCsiCr8PsZSOfoJ6NrGPCOxjHkai9Io=.3181371d-f2e7-4812-981f-50b865613ee2@github.com>

> Fixes SetTag/GetTag JVMTI functions so they consider equal value object as a single object.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1444/files
  - new: https://git.openjdk.org/valhalla/pull/1444/files/2dbe102d..3f6f5cd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1444&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1444&range=00-01

  Stats: 42 lines in 4 files changed: 1 ins; 14 del; 27 mod
  Patch: https://git.openjdk.org/valhalla/pull/1444.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1444/head:pull/1444

PR: https://git.openjdk.org/valhalla/pull/1444

From liach at openjdk.org  Sat Apr 26 15:03:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 15:03:00 GMT
Subject: [lworld] RFR: 8354694: [lworld] Refactor AssertUnsetFields to
 Early Larval Frame
In-Reply-To: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
References: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
Message-ID: <p32DCtCA6DYS-qIS70_CuYm5XlgcjLSTZE06Yqwlqw0=.064951f8-b9f7-4536-bdc2-a903c13418a5@github.com>

On Wed, 16 Apr 2025 21:48:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch adds refactors so the runtime aligns with the new strict field initialization spec (https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html). The stackmap table entry `AssertUnsetFields` is now referred to as `Early_Larval` and it follows a new format where it is a frame that encompasses a base frame.

@matias9927 Can you support `assert_unset_fields` in `stackMapTableFormat.hpp`?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1435#issuecomment-2832300546

From liach at openjdk.org  Sat Apr 26 17:37:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 17:37:51 GMT
Subject: [lworld] RFR: 8354694: [lworld] Refactor AssertUnsetFields to
 Early Larval Frame
In-Reply-To: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
References: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
Message-ID: <KFdKSOZqZqoDmqfFev1nr6T7cllzSHlXSTDz-0yYYzs=.89d9cffb-4a98-4c1f-9f6d-08ece90b1228@github.com>

On Wed, 16 Apr 2025 21:48:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch adds refactors so the runtime aligns with the new strict field initialization spec (https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html). The stackmap table entry `AssertUnsetFields` is now referred to as `Early_Larval` and it follows a new format where it is a frame that encompasses a base frame.

Nevermind, we will do that in another effort I suppose, though that currently affects VM's error messages

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

PR Comment: https://git.openjdk.org/valhalla/pull/1435#issuecomment-2832461771

From liach at openjdk.org  Sat Apr 26 17:38:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 17:38:13 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
Message-ID: <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>

> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
> 
> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
> 
> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.

Chen Liang 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 six additional commits since the last revision:

 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
 - Tweaks to let tests pass
 - Chen comment
 - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
 - Review suggestions, also rollback the getEntryType rename in javac, test updates
 - 8354728: [lworld] Langtools work to update strict implementation to latest

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1432/files
  - new: https://git.openjdk.org/valhalla/pull/1432/files/52d38be4..8ee7a891

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1432&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1432&range=01-02

  Stats: 988 lines in 41 files changed: 409 ins; 377 del; 202 mod
  Patch: https://git.openjdk.org/valhalla/pull/1432.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1432/head:pull/1432

PR: https://git.openjdk.org/valhalla/pull/1432

From liach at openjdk.org  Sat Apr 26 17:41:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 17:41:53 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
Message-ID: <L0VzmNtsD9PQIVrJHxKKOZYP8fbAzwaYgWUtXhB6Kh8=.93a2c3c1-be93-407c-9793-b37a6aff51bc@github.com>

On Sat, 26 Apr 2025 17:38:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>  - Tweaks to let tests pass
>  - Chen comment
>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>  - 8354728: [lworld] Langtools work to update strict implementation to latest

I have picked Matias's patch #1435 over; there are 2 cases that VM has some trouble with, but otherwise tier 1 and 2 tests run fine besides some known varhandle compiler tests.

Integrating this as this is required for us to merge mainline in the future.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1432#issuecomment-2832467734

From duke at openjdk.org  Sat Apr 26 17:41:53 2025
From: duke at openjdk.org (duke)
Date: Sat, 26 Apr 2025 17:41:53 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
Message-ID: <HZp0BhEUfFB1ChKJhPKFZQalhjJj3Yn3KOw7XvdL_CM=.4a733386-17c9-4309-8613-e0abc05f6063@github.com>

On Sat, 26 Apr 2025 17:38:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>  - Tweaks to let tests pass
>  - Chen comment
>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>  - 8354728: [lworld] Langtools work to update strict implementation to latest

@liach 
Your change (at version 8ee7a8917238aa33fc4e4168d1a0ae8f18dacedf) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1432#issuecomment-2832469034

From swen at openjdk.org  Sun Apr 27 02:41:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 27 Apr 2025 02:41:59 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
Message-ID: <NP46oNWHrngMHFzg4HwZfS03sWwqtGmqtT4ixUN6vTE=.c762e0ad-6f95-4bc2-96cd-bda676ae8b91@github.com>

On Sat, 26 Apr 2025 17:38:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>  - Tweaks to let tests pass
>  - Chen comment
>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>  - 8354728: [lworld] Langtools work to update strict implementation to latest

src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 301:

> 299:                         continue;
> 300:                     }
> 301:                     case 247 -> {

Although not related to this PR, why is it that only StackMapDecoder.EARLY_LARVAL uses constants, but the others use magic numbers?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2061956381

From liach at openjdk.org  Sun Apr 27 02:48:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 02:48:00 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <NP46oNWHrngMHFzg4HwZfS03sWwqtGmqtT4ixUN6vTE=.c762e0ad-6f95-4bc2-96cd-bda676ae8b91@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
 <NP46oNWHrngMHFzg4HwZfS03sWwqtGmqtT4ixUN6vTE=.c762e0ad-6f95-4bc2-96cd-bda676ae8b91@github.com>
Message-ID: <K3DBAcscPhdS89Tc3sitY0JxJC851fa4vHNpboFi7rI=.6bfb77b4-9204-443e-9893-1dcb57644cb3@github.com>

On Sun, 27 Apr 2025 02:39:05 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Chen Liang 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>>  - Tweaks to let tests pass
>>  - Chen comment
>>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>>  - 8354728: [lworld] Langtools work to update strict implementation to latest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 301:
> 
>> 299:                         continue;
>> 300:                     }
>> 301:                     case 247 -> {
> 
> Although not related to this PR, why is it that only StackMapDecoder.EARLY_LARVAL uses constants, but the others use magic numbers?

We periodically merge from mainline JDK. These are in mainline; we don't want to create redundant merge conflicts. There is a mainline bug entry for this, feel free to contribute: https://bugs.openjdk.org/browse/JDK-8354871

I think such a contribution will be more welcomed by other reviewers compared to domain-specific optimizations.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2061963357

From swen at openjdk.org  Sun Apr 27 02:54:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 27 Apr 2025 02:54:59 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
Message-ID: <XWJbcgrLH9rkxJBbAd0OqWB9bxcEWlx1Xf7HFz-mF5w=.47c1d10a-eca3-4b0b-8625-b187d8a3e8a9@github.com>

On Sat, 26 Apr 2025 17:38:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>  - Tweaks to let tests pass
>  - Chen comment
>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>  - 8354728: [lworld] Langtools work to update strict implementation to latest

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1268:

> 1266:                 if (debugstackmap) System.out.print("  " + i + ":");
> 1267:                 StackMapTableFrame frame = code.stackMapTableBuffer[i];
> 1268:                 frame.write(this);

code.stackMapTableBuffer[i].write(this);

This variable is only used once, can it be removed?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2061965442

From swen at openjdk.org  Sun Apr 27 03:08:03 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 27 Apr 2025 03:08:03 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
Message-ID: <W1d7NdrjoY8DVbxzcKiDT7XslifFTzp4X14hXR4JcZU=.c8898ecb-e5d7-44e5-ace9-56696a7edf7d@github.com>

On Sat, 26 Apr 2025 17:38:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>  - Tweaks to let tests pass
>  - Chen comment
>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>  - 8354728: [lworld] Langtools work to update strict implementation to latest

Changes requested by swen (no project role).

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1368:

> 1366:         }
> 1367: 
> 1368:         static class SameLocals1StackItemFrame extends StackMapTableFrame {

static final class SameLocals1StackItemFrame extends StackMapTableFrame {

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

PR Review: https://git.openjdk.org/valhalla/pull/1432#pullrequestreview-2796887853
PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2061973795

From liach at openjdk.org  Sun Apr 27 03:08:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 03:08:03 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <XWJbcgrLH9rkxJBbAd0OqWB9bxcEWlx1Xf7HFz-mF5w=.47c1d10a-eca3-4b0b-8625-b187d8a3e8a9@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
 <XWJbcgrLH9rkxJBbAd0OqWB9bxcEWlx1Xf7HFz-mF5w=.47c1d10a-eca3-4b0b-8625-b187d8a3e8a9@github.com>
Message-ID: <hUS76lRDbxFF6mL6bzyUWzqUC5u4-0Cmy7M6rPymDKo=.a87c8909-3ec2-43ca-a011-0b43cff1fdbb@github.com>

On Sun, 27 Apr 2025 02:51:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Chen Liang 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>>  - Tweaks to let tests pass
>>  - Chen comment
>>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>>  - 8354728: [lworld] Langtools work to update strict implementation to latest
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1268:
> 
>> 1266:                 if (debugstackmap) System.out.print("  " + i + ":");
>> 1267:                 StackMapTableFrame frame = code.stackMapTableBuffer[i];
>> 1268:                 frame.write(this);
> 
> code.stackMapTableBuffer[i].write(this);
> 
> This variable is only used once, can it be removed?

This patch is made by IDE during renames. The patch here is incomplete; we might have a complete patch when value objects jep has its pull request, I think.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2061974401

From qamai at openjdk.org  Sun Apr 27 12:07:09 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 27 Apr 2025 12:07:09 GMT
Subject: [lworld] RFR: 8355397: [lworld] Parse::array_load fails with
 "array can't be flat" assert
Message-ID: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>

Hi,

The issue here is that `InstanceKlass::flat_array` is too strict and it rejects any class that is atomic and has more than 1 field. I remove the unnecessary restrictions and rename the method to `maybe_flat_in_array` to illustrate the functionality in a clearer manner.

Please kindly review, thanks a lot.

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

Commit messages:
 - add tests
 - fix InstanceKlass::flat_array

Changes: https://git.openjdk.org/valhalla/pull/1446/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1446&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355397
  Stats: 57 lines in 16 files changed: 26 ins; 8 del; 23 mod
  Patch: https://git.openjdk.org/valhalla/pull/1446.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1446/head:pull/1446

PR: https://git.openjdk.org/valhalla/pull/1446

From qamai at openjdk.org  Sun Apr 27 13:23:02 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 27 Apr 2025 13:23:02 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
Message-ID: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>

Hi

The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects.

It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE.

An example regarding the issue with tracking the identity of a larval InlineTypeNode:

Consider this pseudobytecode sequence:

    new MyValue;
    dup;
    loop;
    invokespecial MyValue::<init>;
    areturn;

There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object.

Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - remove larval InlineTypeNode

Changes: https://git.openjdk.org/valhalla/pull/1447/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335256
  Stats: 732 lines in 17 files changed: 291 ins; 313 del; 128 mod
  Patch: https://git.openjdk.org/valhalla/pull/1447.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1447/head:pull/1447

PR: https://git.openjdk.org/valhalla/pull/1447

From thartmann at openjdk.org  Mon Apr 28 08:52:01 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 28 Apr 2025 08:52:01 GMT
Subject: [lworld] RFR: 8354068: [lworld] Fold strict final fields more
 aggressively [v6]
In-Reply-To: <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
 <w1LSqoo3JUjxal4nlP_VoGnkAwG90biyUavZVMIy1bo=.8e722317-6773-4bbb-9b10-5637ce0c75bf@github.com>
Message-ID: <fPGtnO0cUoC65oMtv6r3H5Nj9jXhvwYrs2vZ2pyJT1c=.23157a34-25ed-4b5b-85a7-656d2948d7a7@github.com>

On Thu, 24 Apr 2025 14:31:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   identation

Sure, sorry for the delay!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2834483816

From qamai at openjdk.org  Mon Apr 28 08:52:01 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 28 Apr 2025 08:52:01 GMT
Subject: [lworld] Integrated: 8354068: [lworld] Fold strict final fields more
 aggressively
In-Reply-To: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
References: <WYKNtxZJTkJkpnWEBsHaNya9idZpGqTLuw2z2QxcLi8=.973da836-1f0d-4547-b647-5520b3f64f02@github.com>
Message-ID: <NuXCDVOBCtKjgTQRL0blseBlUiXbMdhfljYoBbkuIm8=.e769b5b5-29ac-455f-8ac6-afc66ec54637@github.com>

On Tue, 8 Apr 2025 19:17:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> When we do incremental inlining, we need to be more aggressive to ensure that value objects are not unexpectedly materialized. This is done by trying to fold loads from strict final fields in an aggressive manner.
> 
> Please take a look and leave your reviews, thanks a lot.

This pull request has now been integrated.

Changeset: 02b8c1ee
Author:    Quan Anh Mai <qamai at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/02b8c1ee5c92c350e4a965b514b344a328f0b987
Stats:     243 lines in 2 files changed: 224 ins; 1 del; 18 mod

8354068: [lworld] Fold strict final fields more aggressively

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1424

From qamai at openjdk.org  Mon Apr 28 14:30:48 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 28 Apr 2025 14:30:48 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
 [v2]
In-Reply-To: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>
References: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>
Message-ID: <ftlhbeV6BwIDNpyiEZAsOWsxxrzHr1nzEJ8csdPkkFE=.9b27b784-d53c-40cf-bc3b-e36261286453@github.com>

> Hi
> 
> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects.
> 
> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE.
> 
> An example regarding the issue with tracking the identity of a larval InlineTypeNode:
> 
> Consider this pseudobytecode sequence:
> 
>     new MyValue;
>     dup;
>     loop;
>     invokespecial MyValue::<init>;
>     areturn;
> 
> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai 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 two additional commits since the last revision:

 - Merge branch 'lworld' into larvaloop
 - remove larval InlineTypeNode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1447/files
  - new: https://git.openjdk.org/valhalla/pull/1447/files/ae3ed360..d9e233ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=00-01

  Stats: 304 lines in 6 files changed: 278 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/valhalla/pull/1447.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1447/head:pull/1447

PR: https://git.openjdk.org/valhalla/pull/1447

From qamai at openjdk.org  Mon Apr 28 14:46:42 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 28 Apr 2025 14:46:42 GMT
Subject: [lworld] RFR: 8355397: [lworld] Parse::array_load fails with
 "array can't be flat" assert [v2]
In-Reply-To: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
References: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
Message-ID: <rpTowo3HZoDg2PQ6ye8hdHZxYzAsnOwRpsKnNimNyeE=.4c6f250c-3508-4b6f-b771-696c92de5c8e@github.com>

> Hi,
> 
> The issue here is that `InstanceKlass::flat_array` is too strict and it rejects any class that is atomic and has more than 1 field. I remove the unnecessary restrictions and rename the method to `maybe_flat_in_array` to illustrate the functionality in a clearer manner.
> 
> Please kindly review, thanks a lot.

Quan Anh Mai 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:

 - Merge branch 'lworld' into flatinarray
 - add tests
 - fix InstanceKlass::flat_array

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1446/files
  - new: https://git.openjdk.org/valhalla/pull/1446/files/fcfd9334..55e444a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1446&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1446&range=00-01

  Stats: 304 lines in 6 files changed: 278 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/valhalla/pull/1446.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1446/head:pull/1446

PR: https://git.openjdk.org/valhalla/pull/1446

From liach at openjdk.org  Mon Apr 28 15:20:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 15:20:01 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <W1d7NdrjoY8DVbxzcKiDT7XslifFTzp4X14hXR4JcZU=.c8898ecb-e5d7-44e5-ace9-56696a7edf7d@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
 <W1d7NdrjoY8DVbxzcKiDT7XslifFTzp4X14hXR4JcZU=.c8898ecb-e5d7-44e5-ace9-56696a7edf7d@github.com>
Message-ID: <f91Fq6yGCZGCgC8slVgvaWh0lmM_fNAJeuiS1HmolFU=.e5846c0d-d451-42b0-be6b-a95f3340174c@github.com>

On Sun, 27 Apr 2025 03:03:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Chen Liang 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>>  - Tweaks to let tests pass
>>  - Chen comment
>>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>>  - 8354728: [lworld] Langtools work to update strict implementation to latest
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1368:
> 
>> 1366:         }
>> 1367: 
>> 1368:         static class SameLocals1StackItemFrame extends StackMapTableFrame {
> 
> static final class SameLocals1StackItemFrame extends StackMapTableFrame {

We will refrain from touching this for now for parity with mainline.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2063900575

From rriggs at openjdk.org  Mon Apr 28 16:08:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Apr 2025 16:08:03 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
Message-ID: <JUWhARMAT64Sc6JVMeCyqc-9AMmSHNF32cavhaorATk=.083146df-2c4a-4b29-99f9-5f04de783ed0@github.com>

On Sat, 26 Apr 2025 17:38:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>  - Tweaks to let tests pass
>  - Chen comment
>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>  - 8354728: [lworld] Langtools work to update strict implementation to latest

Looks ok, though I don't have much experience with javac.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 372:

> 370: 
> 371:     /**
> 372:      * The access flag {@code ACC_STRICT_INIT}, with a mask

Is the reference Modifier#STRICT still relevant?
The description in java.lang.Modifier is obsolete for JDK 25 (and some previous versions).
It could be expanded to cover the release specific cases. 
The Modifier.isStrict() method is also dated.  Maybe that's a separate issue.

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

PR Review: https://git.openjdk.org/valhalla/pull/1432#pullrequestreview-2799669877
PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2063883626

From liach at openjdk.org  Mon Apr 28 16:08:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 16:08:03 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <JUWhARMAT64Sc6JVMeCyqc-9AMmSHNF32cavhaorATk=.083146df-2c4a-4b29-99f9-5f04de783ed0@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
 <JUWhARMAT64Sc6JVMeCyqc-9AMmSHNF32cavhaorATk=.083146df-2c4a-4b29-99f9-5f04de783ed0@github.com>
Message-ID: <AjEO_IynW-zkuest6_rQSfLZun2ewSDcE_kx9sr6I1g=.1ac87a9d-186e-4be3-81bc-226a222109a4@github.com>

On Mon, 28 Apr 2025 15:11:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chen Liang 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/unset-update
>>  - Tweaks to let tests pass
>>  - Chen comment
>>  - 8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame
>>  - Review suggestions, also rollback the getEntryType rename in javac, test updates
>>  - 8354728: [lworld] Langtools work to update strict implementation to latest
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 372:
> 
>> 370: 
>> 371:     /**
>> 372:      * The access flag {@code ACC_STRICT_INIT}, with a mask
> 
> Is the reference Modifier#STRICT still relevant?
> The description in java.lang.Modifier is obsolete for JDK 25 (and some previous versions).
> It could be expanded to cover the release specific cases. 
> The Modifier.isStrict() method is also dated.  Maybe that's a separate issue.

Indeed; should I change the value rendering to `{@code}` like that for INTERFACE to prevent misleading links?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2064005892

From matsaave at openjdk.org  Mon Apr 28 16:50:02 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 28 Apr 2025 16:50:02 GMT
Subject: [lworld] RFR: 8354694: [lworld] Refactor AssertUnsetFields to
 Early Larval Frame
In-Reply-To: <h-kW5vLadpKCkWaQi-0zcNIDIEemvjJR1jzwta_2L1c=.30e608a0-d9ba-4953-a6af-d3201d3fee9f@github.com>
References: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
 <h-kW5vLadpKCkWaQi-0zcNIDIEemvjJR1jzwta_2L1c=.30e608a0-d9ba-4953-a6af-d3201d3fee9f@github.com>
Message-ID: <Jni2NkYHi0AzCHrQuGX7IzHhcOMfQRBZtD-elVVwkSw=.6feda29e-3bff-41d5-b906-dd11c034eb5a@github.com>

On Thu, 17 Apr 2025 05:43:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch adds refactors so the runtime aligns with the new strict field initialization spec (https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html). The stackmap table entry `AssertUnsetFields` is now referred to as `Early_Larval` and it follows a new format where it is a frame that encompasses a base frame.
>
> src/hotspot/share/classfile/stackMapTable.cpp line 298:
> 
>> 296:     _parsed_frame_count++;
>> 297:   }
>> 298: 
> 
> If we have no early_larval wrapping, and there is no more `uninitializedThis` in locals, we implicitly set unset fields to empty. See last sentence in section 4.7.4.
> 
> So for control flow like:
> 
> 
> if (check) {} else {}
> this.strictField = xxx;
> super();
> if (check1) {} else {}
> 
> The frame at first then-else merge has `strictField` unset, but the frame at 2nd else branch off must not be wrapped in early_larval, and verifier must accordingly clear the unset fields.

I'm not following. Placing a non-empty Early_Larval frame with without `uninitializedThis` results ina verify error.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1435#discussion_r2064083617

From liach at openjdk.org  Mon Apr 28 17:13:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 17:13:00 GMT
Subject: [lworld] RFR: 8354694: [lworld] Refactor AssertUnsetFields to
 Early Larval Frame
In-Reply-To: <Jni2NkYHi0AzCHrQuGX7IzHhcOMfQRBZtD-elVVwkSw=.6feda29e-3bff-41d5-b906-dd11c034eb5a@github.com>
References: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
 <h-kW5vLadpKCkWaQi-0zcNIDIEemvjJR1jzwta_2L1c=.30e608a0-d9ba-4953-a6af-d3201d3fee9f@github.com>
 <Jni2NkYHi0AzCHrQuGX7IzHhcOMfQRBZtD-elVVwkSw=.6feda29e-3bff-41d5-b906-dd11c034eb5a@github.com>
Message-ID: <WhVDn9K2VgZEPlsPwJtwFtLkJqC8QqETtZMkUb73Fkw=.b8d6ac36-a7b0-414c-b0a6-a466db696270@github.com>

On Mon, 28 Apr 2025 16:47:34 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> src/hotspot/share/classfile/stackMapTable.cpp line 298:
>> 
>>> 296:     _parsed_frame_count++;
>>> 297:   }
>>> 298: 
>> 
>> If we have no early_larval wrapping, and there is no more `uninitializedThis` in locals, we implicitly set unset fields to empty. See last sentence in section 4.7.4.
>> 
>> So for control flow like:
>> 
>> 
>> if (check) {} else {}
>> this.strictField = xxx;
>> super();
>> if (check1) {} else {}
>> 
>> The frame at first then-else merge has `strictField` unset, but the frame at 2nd else branch off must not be wrapped in early_larval, and verifier must accordingly clear the unset fields.
>
> I'm not following. Placing a non-empty Early_Larval frame with without `uninitializedThis` results ina verify error.

Good. You must have cleared the unset fields when flagThisUninit is not set in somewhere else.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1435#discussion_r2064120571

From liach at openjdk.org  Mon Apr 28 17:16:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 17:16:24 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v4]
In-Reply-To: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
Message-ID: <FR8cysn2UiuSetcsgdfjBoF9TkEiBvl_AM9tISaa-vA=.e8da44c8-860b-4031-9b16-e052312d3c11@github.com>

> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
> 
> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
> 
> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Roger comment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1432/files
  - new: https://git.openjdk.org/valhalla/pull/1432/files/8ee7a891..867796f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1432&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1432&range=02-03

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1432.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1432/head:pull/1432

PR: https://git.openjdk.org/valhalla/pull/1432

From liach at openjdk.org  Mon Apr 28 17:45:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 17:45:58 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v3]
In-Reply-To: <AjEO_IynW-zkuest6_rQSfLZun2ewSDcE_kx9sr6I1g=.1ac87a9d-186e-4be3-81bc-226a222109a4@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <aHRuBGTf9pAC4_mCf-v2OWVuLcCqHwP8cBVs7evJ2vw=.7c65f566-8631-4d64-8172-2802fe91de48@github.com>
 <JUWhARMAT64Sc6JVMeCyqc-9AMmSHNF32cavhaorATk=.083146df-2c4a-4b29-99f9-5f04de783ed0@github.com>
 <AjEO_IynW-zkuest6_rQSfLZun2ewSDcE_kx9sr6I1g=.1ac87a9d-186e-4be3-81bc-226a222109a4@github.com>
Message-ID: <IeE3SlqAP_YYVNQWSZiP9sgDwG40X4xJOE-W9TYVkQQ=.ae1adcc6-180f-4c43-91d3-80565a842746@github.com>

On Mon, 28 Apr 2025 16:05:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 372:
>> 
>>> 370: 
>>> 371:     /**
>>> 372:      * The access flag {@code ACC_STRICT_INIT}, with a mask
>> 
>> Is the reference Modifier#STRICT still relevant?
>> The description in java.lang.Modifier is obsolete for JDK 25 (and some previous versions).
>> It could be expanded to cover the release specific cases. 
>> The Modifier.isStrict() method is also dated.  Maybe that's a separate issue.
>
> Indeed; should I change the value rendering to `{@code}` like that for INTERFACE to prevent misleading links?

Done; I have unlinked ACC_STRICT_INIT from Modifier.STRICT.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1432#discussion_r2064174853

From vromero at openjdk.org  Mon Apr 28 17:57:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Apr 2025 17:57:03 GMT
Subject: [lworld] RFR: 8354728: [lworld] Langtools work to update strict
 implementation to latest [v4]
In-Reply-To: <FR8cysn2UiuSetcsgdfjBoF9TkEiBvl_AM9tISaa-vA=.e8da44c8-860b-4031-9b16-e052312d3c11@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
 <FR8cysn2UiuSetcsgdfjBoF9TkEiBvl_AM9tISaa-vA=.e8da44c8-860b-4031-9b16-e052312d3c11@github.com>
Message-ID: <v36iVlcQquTXJq8ZVt-0gSY9pmb5AyWXwX6MRzkdzTo=.f0976d3c-1b5d-4d2f-acec-7321f6fd7a4b@github.com>

On Mon, 28 Apr 2025 17:16:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
>> 
>> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
>> 
>> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger comment

looks sensible

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1432#pullrequestreview-2800174940

From liach at openjdk.org  Mon Apr 28 18:05:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 18:05:06 GMT
Subject: [lworld] Integrated: 8354728: [lworld] Langtools work to update strict
 implementation to latest
In-Reply-To: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
References: <ehNGLAFGKn3wyGLjUe8FhkxbCJ80U9FhKDTdELDKyL8=.57492e7b-7702-475e-8143-81523ae22f7a@github.com>
Message-ID: <xD_KOktudbYunHPNPwp_581Rnb-XanaBl2TD4mz6jxA=.536c7594-cd99-45ab-be35-294cd7a5a6cf@github.com>

On Tue, 15 Apr 2025 23:35:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> The updates to the core libraries + langtools for the latest strict field initialization spec https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html is ready.
> 
> Currently, since there is no VM support, testing is restricted to generation by ClassFile API/javac and inspection through ClassFile API (and javap)
> 
> Not suitable for integration yet; StrictFinalInstanceFieldsTest requires VM side's support.

This pull request has now been integrated.

Changeset: 537cdc4c
Author:    Chen Liang <liach at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/537cdc4cc1530901d90f3d9114eb19c92f739d75
Stats:     630 lines in 19 files changed: 298 ins; 93 del; 239 mod

8354728: [lworld] Langtools work to update strict implementation to latest
8354694: [lworld] Refactor AssertUnsetFields to Early Larval Frame

Co-authored-by: Matias Saavedra Silva <matsaave at openjdk.org>
Reviewed-by: vromero

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

PR: https://git.openjdk.org/valhalla/pull/1432

From matsaave at openjdk.org  Mon Apr 28 18:14:56 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 28 Apr 2025 18:14:56 GMT
Subject: [lworld] Withdrawn: 8354694: [lworld] Refactor AssertUnsetFields to
 Early Larval Frame
In-Reply-To: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
References: <Xz8kPSQjODDI3-U-s0V3nwAFUflWH-RKCthkJjJndlg=.db9c6f2c-a1ef-4bac-91cc-4726427a9d93@github.com>
Message-ID: <OFRRozrjLTLOIpKLH-16R2zjT5MjuRd2Gec8zc0Y7bI=.cf3d65db-207e-4b50-9493-b71523ac3ac6@github.com>

On Wed, 16 Apr 2025 21:48:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch adds refactors so the runtime aligns with the new strict field initialization spec (https://cr.openjdk.org/~dlsmith/jep401/jep401-20250409/specs/strict-fields-jvms.html). The stackmap table entry `AssertUnsetFields` is now referred to as `Early_Larval` and it follows a new format where it is a frame that encompasses a base frame.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/valhalla/pull/1435

From thartmann at openjdk.org  Tue Apr 29 08:39:13 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 29 Apr 2025 08:39:13 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
 [v2]
In-Reply-To: <ftlhbeV6BwIDNpyiEZAsOWsxxrzHr1nzEJ8csdPkkFE=.9b27b784-d53c-40cf-bc3b-e36261286453@github.com>
References: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>
 <ftlhbeV6BwIDNpyiEZAsOWsxxrzHr1nzEJ8csdPkkFE=.9b27b784-d53c-40cf-bc3b-e36261286453@github.com>
Message-ID: <yuQjjfQNI6DQMKnx0mM2fOM1-8UjUec6FFhH9wc_t-g=.45143a5d-1497-4448-86a1-7f4d9c3540f5@github.com>

On Mon, 28 Apr 2025 14:30:48 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi
>> 
>> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects.
>> 
>> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE.
>> 
>> An example regarding the issue with tracking the identity of a larval InlineTypeNode:
>> 
>> Consider this pseudobytecode sequence:
>> 
>>     new MyValue;
>>     dup;
>>     loop;
>>     invokespecial MyValue::<init>;
>>     areturn;
>> 
>> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai 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 two additional commits since the last revision:
> 
>  - Merge branch 'lworld' into larvaloop
>  - remove larval InlineTypeNode

Great work @merykitty! Thanks a lot for the investigation. When working on the new value object construction model, I was concerned that we might end up with adding identity back to the larvals but I was still naively hoping that we could get around that. Looks like we can't. Maybe you could change the title to something more descriptive for future reference / search.

I run this through testing and there are a few issues:


applications/ctw/modules/jdk_internal_le.java
-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/workspace/open/src/hotspot/share/opto/macro.cpp:2970), pid=1140043, tid=1140412
#  assert(!n->as_AbstractLock()->is_eliminated()) failed: sanity
#
# JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x15359a4]  PhaseMacroExpand::eliminate_macro_nodes()+0x714

Current CompileTask:
C2:26441 3356   !b        jdk.internal.org.jline.utils.NonBlockingInputStreamImpl::run (312 bytes)

Stack: [0x00007f27dbbfd000,0x00007f27dbcfd000],  sp=0x00007f27dbcf8250,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x15359a4]  PhaseMacroExpand::eliminate_macro_nodes()+0x714  (macro.cpp:2970)
V  [libjvm.so+0xb26617]  Compile::Optimize()+0x1867  (compile.cpp:2903)
V  [libjvm.so+0xb28ceb]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1feb  (compile.cpp:874)
V  [libjvm.so+0x94e98d]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x46d  (c2compiler.cpp:142)
V  [libjvm.so+0xb379f2]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb22  (compileBroker.cpp:2307)
V  [libjvm.so+0xb389f8]  CompileBroker::compiler_thread_loop()+0x588  (compileBroker.cpp:1951)
V  [libjvm.so+0x109191f]  JavaThread::thread_main_inner()+0x12f  (javaThread.cpp:773)
V  [libjvm.so+0x1abf606]  Thread::call_run()+0xb6  (thread.cpp:231)
V  [libjvm.so+0x17466d8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:877)




compiler/valhalla/inlinetypes/TestValueClasses.java
-DWarmup=0 -DVerifyIR=false 
OR
-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true

Caused by: java.lang.RuntimeException: assertEquals expected: compiler.valhalla.inlinetypes.TestValueClasses$SmallNullable1 at b0186fd4 but was: compiler.valhalla.inlinetypes.TestValueClasses$SmallNullable1 at 6279ef0a
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:195)
	at jdk.test.lib.Asserts.assertEQ(Asserts.java:172)
	at compiler.valhalla.inlinetypes.TestValueClasses.test9_verifier(TestValueClasses.java:434)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more



compiler/valhalla/inlinetypes/TestValueConstruction.java
-XX:+UnlockDiagnosticVMOptions -XX:+AbortVMOnCompilationFailure

This is expected but to be able to run this test with `-XX:+AbortVMOnCompilationFailure`, which is valuable, maybe we should put your new test in another jtreg test and hardcode `-XX:-AbortVMOnCompilationFailure` there?

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (workspace/open/src/hotspot/share/compiler/compileBroker.cpp:2114), pid=2843210, tid=2843229
#  fatal error: Not compilable at tier 4: OSR starts with non-empty stack
#
# JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xb30beb]  CompileBroker::handle_compile_error(CompilerThread*, CompileTask*, ciEnv*, int, char const*)+0x6b

Current CompileTask:
C2:6345 1087 %  b  4       compiler.valhalla.inlinetypes.TestValueConstruction$Code_0::multipleOccurrencesInJVMSReturnStack @ 5 (22 bytes)

Stack: [0x00007fc85457f000,0x00007fc85467f000],  sp=0x00007fc85467d450,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xb30beb]  CompileBroker::handle_compile_error(CompilerThread*, CompileTask*, ciEnv*, int, char const*)+0x6b  (compileBroker.cpp:2114)
V  [libjvm.so+0xb3734c]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x47c  (compileBroker.cpp:2340)
V  [libjvm.so+0xb389f8]  CompileBroker::compiler_thread_loop()+0x588  (compileBroker.cpp:1951)
V  [libjvm.so+0x109191f]  JavaThread::thread_main_inner()+0x12f  (javaThread.cpp:773)
V  [libjvm.so+0x1abf606]  Thread::call_run()+0xb6  (thread.cpp:231)
V  [libjvm.so+0x17466d8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:877)



compiler/valhalla/inlinetypes/TestValueConstruction.java

Various flags:
- No flags
- "-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressArrayCopyMacroNode -XX:+StressCallingConvention -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP -XX:+StressIGVN -XX:+StressReflectiveCode -XX:+StressMethodHandleLinkerInlining -XX:+StressCompiledExceptionHandlers -XX:MaxNodeLimit=100000"

java.lang.RuntimeException: assertEquals expected: x: 0 but was: x: 50000
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:195)
	at jdk.test.lib.Asserts.assertEQ(Asserts.java:172)
	at compiler.valhalla.inlinetypes.TestValueConstruction.check(TestValueConstruction.java:1851)
	at compiler.valhalla.inlinetypes.TestValueConstruction.run(TestValueConstruction.java:1846)
	at compiler.valhalla.inlinetypes.TestValueConstruction.main(TestValueConstruction.java:1773)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2837948418

From thartmann at openjdk.org  Tue Apr 29 08:42:02 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 29 Apr 2025 08:42:02 GMT
Subject: [lworld] RFR: 8355397: [lworld] Parse::array_load fails with
 "array can't be flat" assert [v2]
In-Reply-To: <rpTowo3HZoDg2PQ6ye8hdHZxYzAsnOwRpsKnNimNyeE=.4c6f250c-3508-4b6f-b771-696c92de5c8e@github.com>
References: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
 <rpTowo3HZoDg2PQ6ye8hdHZxYzAsnOwRpsKnNimNyeE=.4c6f250c-3508-4b6f-b771-696c92de5c8e@github.com>
Message-ID: <yxIHztfv6zAooFW5jdgXkGaDPpU0011-hB2gNtFBYF4=.51b61d07-b943-4826-b00c-1e09b1ea0ccf@github.com>

On Mon, 28 Apr 2025 14:46:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> The issue here is that `InstanceKlass::flat_array` is too strict and it rejects any class that is atomic and has more than 1 field. I remove the unnecessary restrictions and rename the method to `maybe_flat_in_array` to illustrate the functionality in a clearer manner.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai 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:
> 
>  - Merge branch 'lworld' into flatinarray
>  - add tests
>  - fix InstanceKlass::flat_array

Thanks for fixing this, @merykitty! Looks good to me and all tests pass.

src/hotspot/share/ci/ciMetadata.hpp line 64:

> 62:   virtual bool is_type_array_klass() const  { return false; }
> 63:   virtual bool is_wrapper() const           { return false; }
> 64:   virtual bool maybe_flat_in_array() const        { return false; }

Maybe fix the indentation here.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1446#pullrequestreview-2802524477
PR Review Comment: https://git.openjdk.org/valhalla/pull/1446#discussion_r2065799610

From qamai at openjdk.org  Tue Apr 29 19:52:20 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 29 Apr 2025 19:52:20 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
 [v3]
In-Reply-To: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>
References: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>
Message-ID: <mRADxpzmMyn8Z8n3M-dPhCWeXoR21TO5Pl18Mx3ZPas=.4453436b-fd6f-4c9f-a46a-b2bd88bc1cc5@github.com>

> Hi
> 
> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects.
> 
> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE.
> 
> An example regarding the issue with tracking the identity of a larval InlineTypeNode:
> 
> Consider this pseudobytecode sequence:
> 
>     new MyValue;
>     dup;
>     loop;
>     invokespecial MyValue::<init>;
>     areturn;
> 
> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix test failures

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1447/files
  - new: https://git.openjdk.org/valhalla/pull/1447/files/d9e233ef..d91fcf99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=01-02

  Stats: 216 lines in 6 files changed: 32 ins; 141 del; 43 mod
  Patch: https://git.openjdk.org/valhalla/pull/1447.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1447/head:pull/1447

PR: https://git.openjdk.org/valhalla/pull/1447

From qamai at openjdk.org  Tue Apr 29 20:02:59 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 29 Apr 2025 20:02:59 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
 [v2]
In-Reply-To: <yuQjjfQNI6DQMKnx0mM2fOM1-8UjUec6FFhH9wc_t-g=.45143a5d-1497-4448-86a1-7f4d9c3540f5@github.com>
References: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>
 <ftlhbeV6BwIDNpyiEZAsOWsxxrzHr1nzEJ8csdPkkFE=.9b27b784-d53c-40cf-bc3b-e36261286453@github.com>
 <yuQjjfQNI6DQMKnx0mM2fOM1-8UjUec6FFhH9wc_t-g=.45143a5d-1497-4448-86a1-7f4d9c3540f5@github.com>
Message-ID: <h4Ep0QWPfM0oqnTPPGksszBmxumpfaUkSVlu7QCBm7Y=.fe5d1b1b-cb05-4a89-bde1-403d50bc5a11@github.com>

On Tue, 29 Apr 2025 08:36:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' into larvaloop
>>  - remove larval InlineTypeNode
>
> Great work @merykitty! Thanks a lot for the investigation. When working on the new value object construction model, I was concerned that we might end up with adding identity back to the larvals but I was still naively hoping that we could get around that. Looks like we can't. Maybe you could change the title to something more descriptive for future reference / search.
> 
> I run this through testing and there are a few issues:
> 
> 
> applications/ctw/modules/jdk_internal_le.java
> -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/workspace/open/src/hotspot/share/opto/macro.cpp:2970), pid=1140043, tid=1140412
> #  assert(!n->as_AbstractLock()->is_eliminated()) failed: sanity
> #
> # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x15359a4]  PhaseMacroExpand::eliminate_macro_nodes()+0x714
> 
> Current CompileTask:
> C2:26441 3356   !b        jdk.internal.org.jline.utils.NonBlockingInputStreamImpl::run (312 bytes)
> 
> Stack: [0x00007f27dbbfd000,0x00007f27dbcfd000],  sp=0x00007f27dbcf8250,  free space=1004k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x15359a4]  PhaseMacroExpand::eliminate_macro_nodes()+0x714  (macro.cpp:2970)
> V  [libjvm.so+0xb26617]  Compile::Optimize()+0x1867  (compile.cpp:2903)
> V  [libjvm.so+0xb28ceb]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1feb  (compile.cpp:874)
> V  [libjvm.so+0x94e98d]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x46d  (c2compiler.cpp:142)
> V  [libjvm.so+0xb379f2]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb22  (compileBroker.cpp:2307)
> V  [libjvm.so+0xb389f8]  CompileBroker::compiler_thread_loop()+0x588  (compileBroker.cpp:1951)
> V  [libjvm.so+0x109191f]  JavaThread::thread_main_inner()+0x12f  (javaThread.cpp:773)
> V  [libjvm.so+0x1abf606]  Thread::call_run()+0xb6  (thread.cpp:231)
> V  [libjvm.so+0x17466d8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:877)
> 
> 
> 
> 
> compiler/valhalla/inlinetypes/TestValueClasses.java
> -DWarmup=0 -DVerifyIR=false 
> OR
> -Xcomp -XX:-TieredCompilation -D...

@TobiHartmann Thanks a lot for the comprehensive testing, it is really helpful.

> applications/ctw/modules/jdk_internal_le.java
-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation

This one fails because after removal of some allocations, not only other allocations become eligible for elimination, locks can also be eliminated. As a result, we need to do the whole macro elimination again. I noticed that `_has_lock` is unused, which makes it trivial to merge the 2 loops, simplify the implementation there.

> compiler/valhalla/inlinetypes/TestValueClasses.java
-DWarmup=0 -DVerifyIR=false 
OR
-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true

This one is an oversight by me. When exiting a constructor, the larval oop is aggressively replaced by the non-larval one in all the frames. This relies on the assumption that all blocks in which the oop is larval has been processed. This is incorrect when we have uncommon traps, which can be processed at any time. As a result, we can only replace the larval oop with the non-larval one in the current frame.

> compiler/valhalla/inlinetypes/TestValueConstruction.java
-XX:+UnlockDiagnosticVMOptions -XX:+AbortVMOnCompilationFailure

I modified the test to push everything into the local slots, 2 distinct slots are present into the loop, keep the original intention of the test.

> compiler/valhalla/inlinetypes/TestValueConstruction.java
Various flags:
> - No flags
> - "-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation

This is interesting. This is an oversight from #1424. The issue is that it is hard to decide that 2 nodes are definitely different or definitely the same, especially when the graph may be non-canonical during IGVN. As a result, I resort to a more conservative approach there:

- Give up finding a matching constructor for a local allocation.
- When deciding if a call can modify a field of a local allocation, don't take into account the receiver and return `true` for any constructor of a subclass regardless of whether the receiver is actually the object we are loading from.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2840098133

From qamai at openjdk.org  Tue Apr 29 20:07:20 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 29 Apr 2025 20:07:20 GMT
Subject: [lworld] RFR: 8355397: [lworld] Parse::array_load fails with
 "array can't be flat" assert [v3]
In-Reply-To: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
References: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
Message-ID: <Kw4QEWy7xeSCinBY9_9HTms4X_jVMQWc67d-LsbL7E0=.d746c4f2-4eea-4373-998e-4528d9be25eb@github.com>

> Hi,
> 
> The issue here is that `InstanceKlass::flat_array` is too strict and it rejects any class that is atomic and has more than 1 field. I remove the unnecessary restrictions and rename the method to `maybe_flat_in_array` to illustrate the functionality in a clearer manner.
> 
> Please kindly review, thanks a lot.

Quan Anh Mai 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 five additional commits since the last revision:

 - Merge branch 'lworld' into flatinarray
 - format
 - Merge branch 'lworld' into flatinarray
 - add tests
 - fix InstanceKlass::flat_array

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1446/files
  - new: https://git.openjdk.org/valhalla/pull/1446/files/55e444a6..926298dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1446&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1446&range=01-02

  Stats: 631 lines in 20 files changed: 298 ins; 93 del; 240 mod
  Patch: https://git.openjdk.org/valhalla/pull/1446.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1446/head:pull/1446

PR: https://git.openjdk.org/valhalla/pull/1446

From qamai at openjdk.org  Tue Apr 29 20:07:21 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 29 Apr 2025 20:07:21 GMT
Subject: [lworld] RFR: 8355397: [lworld] Parse::array_load fails with
 "array can't be flat" assert [v2]
In-Reply-To: <yxIHztfv6zAooFW5jdgXkGaDPpU0011-hB2gNtFBYF4=.51b61d07-b943-4826-b00c-1e09b1ea0ccf@github.com>
References: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
 <rpTowo3HZoDg2PQ6ye8hdHZxYzAsnOwRpsKnNimNyeE=.4c6f250c-3508-4b6f-b771-696c92de5c8e@github.com>
 <yxIHztfv6zAooFW5jdgXkGaDPpU0011-hB2gNtFBYF4=.51b61d07-b943-4826-b00c-1e09b1ea0ccf@github.com>
Message-ID: <9c9CB7HtC4IO3OIJ9xAsOm2QdPnCfRa7iB_Qzs0uMns=.3098b270-eae9-4f22-b04a-079d2635e0f6@github.com>

On Tue, 29 Apr 2025 08:38:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai 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:
>> 
>>  - Merge branch 'lworld' into flatinarray
>>  - add tests
>>  - fix InstanceKlass::flat_array
>
> Thanks for fixing this, @merykitty! Looks good to me and all tests pass.

@TobiHartmann Thanks a lot for your reviews, I have fixed the indentation.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1446#issuecomment-2840106820

From duke at openjdk.org  Tue Apr 29 20:07:21 2025
From: duke at openjdk.org (duke)
Date: Tue, 29 Apr 2025 20:07:21 GMT
Subject: [lworld] RFR: 8355397: [lworld] Parse::array_load fails with
 "array can't be flat" assert [v2]
In-Reply-To: <rpTowo3HZoDg2PQ6ye8hdHZxYzAsnOwRpsKnNimNyeE=.4c6f250c-3508-4b6f-b771-696c92de5c8e@github.com>
References: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
 <rpTowo3HZoDg2PQ6ye8hdHZxYzAsnOwRpsKnNimNyeE=.4c6f250c-3508-4b6f-b771-696c92de5c8e@github.com>
Message-ID: <bBoRLsbbZAI644CS_5Xo_hv4kwjaxD80lkJMlRZKTuY=.81ef0adb-5e47-4a26-a1fc-381fc8394467@github.com>

On Mon, 28 Apr 2025 14:46:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> The issue here is that `InstanceKlass::flat_array` is too strict and it rejects any class that is atomic and has more than 1 field. I remove the unnecessary restrictions and rename the method to `maybe_flat_in_array` to illustrate the functionality in a clearer manner.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai 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:
> 
>  - Merge branch 'lworld' into flatinarray
>  - add tests
>  - fix InstanceKlass::flat_array

@merykitty 
Your change (at version 926298dd7fd7eabebfdfd5070a32724d66dc7e1c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1446#issuecomment-2840108165

From qamai at openjdk.org  Tue Apr 29 20:12:07 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 29 Apr 2025 20:12:07 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
 [v4]
In-Reply-To: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>
References: <A6TfZw7ar2KdQCRwAd45BmCniEofM70aNnPP16m501Q=.1188cfdb-3fce-48ae-8ac2-0f76655ab60c@github.com>
Message-ID: <6MMbO4fn1i6swKVOezub46YyiWLW29JWIvntcqSg-4s=.a5f46c5e-7e66-4125-8b52-4d701182ec6b@github.com>

> Hi
> 
> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects.
> 
> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE.
> 
> An example regarding the issue with tracking the identity of a larval InlineTypeNode:
> 
> Consider this pseudobytecode sequence:
> 
>     new MyValue;
>     dup;
>     loop;
>     invokespecial MyValue::<init>;
>     areturn;
> 
> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fast path for non intrinsics

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1447/files
  - new: https://git.openjdk.org/valhalla/pull/1447/files/d91fcf99..3be7b97b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=02-03

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

PR: https://git.openjdk.org/valhalla/pull/1447

From amenkov at openjdk.org  Wed Apr 30 01:38:04 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 30 Apr 2025 01:38:04 GMT
Subject: [lworld] Integrated: 8355560: SetTag/GetTag should consider equal
 value objects as the same object
In-Reply-To: <xjKQpaZAtF9qPkObbXsXl4CoQyqIHSD3kHmiW83Hxvs=.7d223682-6d63-4fd8-a4de-bd68277bad40@github.com>
References: <xjKQpaZAtF9qPkObbXsXl4CoQyqIHSD3kHmiW83Hxvs=.7d223682-6d63-4fd8-a4de-bd68277bad40@github.com>
Message-ID: <VYk9UBZZV63aSFYvi612kZ9edaHfRk7pg83oqIVvUbU=.480c9c38-966c-4ca6-875f-eb03f97b07e1@github.com>

On Fri, 25 Apr 2025 00:39:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Fixes SetTag/GetTag JVMTI functions so they consider equal value object as a single object.

This pull request has now been integrated.

Changeset: 99de2e7e
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/99de2e7e73c2dd51f516a668cfe2a4bc8ba7ab8d
Stats:     318 lines in 4 files changed: 300 ins; 4 del; 14 mod

8355560: SetTag/GetTag should consider equal value objects as the same object

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

PR: https://git.openjdk.org/valhalla/pull/1444

From qamai at openjdk.org  Wed Apr 30 05:16:59 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 30 Apr 2025 05:16:59 GMT
Subject: [lworld] Integrated: 8355397: [lworld] Parse::array_load fails with
 "array can't be flat" assert
In-Reply-To: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
References: <8eXfCoyY49xSBh56RuDUcBk05LzNg6BvvvaCmwmNOEo=.f54e2ace-3997-40fb-8e3d-318108e701f0@github.com>
Message-ID: <qxb7OB9rASFNliM5oEW-ehu00U8LESOsi7iNHoDXcHo=.91f0295d-f780-4e03-ada3-ea488f3a403f@github.com>

On Sun, 27 Apr 2025 12:03:04 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue here is that `InstanceKlass::flat_array` is too strict and it rejects any class that is atomic and has more than 1 field. I remove the unnecessary restrictions and rename the method to `maybe_flat_in_array` to illustrate the functionality in a clearer manner.
> 
> Please kindly review, thanks a lot.

This pull request has now been integrated.

Changeset: 714930ee
Author:    Quan Anh Mai <qamai at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/714930ee3b79eea215a475a770bcf0544ca4780f
Stats:     57 lines in 16 files changed: 26 ins; 8 del; 23 mod

8355397: [lworld] Parse::array_load fails with "array can't be flat" assert

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1446