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