From vromero at openjdk.org  Sun Feb  1 01:14:23 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 1 Feb 2026 01:14:23 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for local
 variable proxies
Message-ID: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>

adding some additional regression tests for local proxy variables

TIA

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

Commit messages:
 - 8376843: [lworld] add more regression tests for local variable proxies

Changes: https://git.openjdk.org/valhalla/pull/2008/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376843
  Stats: 266 lines in 5 files changed: 240 ins; 12 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/2008.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2008/head:pull/2008

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

From vromero at openjdk.org  Sun Feb  1 01:14:24 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 1 Feb 2026 01:14:24 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies
In-Reply-To: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
Message-ID: <jJiVUJHcv5haBzPECIj4hQ3g3Yf8SSY53vPjq0EOmNk=.e1d9dc77-c863-4291-97a4-c6915df80d6c@github.com>

On Sun, 1 Feb 2026 01:06:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding some additional regression tests for local proxy variables
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1548:

> 1546:                                 if (mode == PrologueVisitorMode.THIS_CONSTRUCTOR) {
> 1547:                                     reportPrologueError(tree, sym);
> 1548:                                 } else if (mode == PrologueVisitorMode.SUPER_CONSTRUCTOR && isInstanceField(tree)) {

not necessary with the current implementation but, not bad to be extra sure, future proof

test/langtools/tools/javac/valhalla/value-objects/LocalProxyVariablesTests.java line 86:

> 84:         doTest(
> 85:                 """
> 86:                 value class Test1 {

even though the compiler used is supposed to be reusable, using the same name for all classes produces an error, would be nice to fix this issue so that we can have a 100% reusable compiler

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2008#discussion_r2750324183
PR Review Comment: https://git.openjdk.org/valhalla/pull/2008#discussion_r2750327255

From vromero at openjdk.org  Sun Feb  1 01:19:07 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 1 Feb 2026 01:19:07 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v2]
In-Reply-To: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
Message-ID: <wOWs91xEF1eaiYHCYXrfw7BJ7inDFoEBaxMsU_c4zUw=.20306ac8-92ca-4344-99da-79eaca8e38d9@github.com>

> adding some additional regression tests for local proxy variables
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  doc

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2008/files
  - new: https://git.openjdk.org/valhalla/pull/2008/files/bc83b6fb..51ca50e3

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

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

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

From vromero at openjdk.org  Sun Feb  1 01:34:26 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 1 Feb 2026 01:34:26 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v3]
In-Reply-To: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
Message-ID: <p_GWL1cU-sn8GU25-z6sme5PqYM1oskbJ1PS2hBtmRA=.6bda9f19-8f27-450e-a3e4-bd9be55b14f3@github.com>

> adding some additional regression tests for local proxy variables
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  making the compiler reusable

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2008/files
  - new: https://git.openjdk.org/valhalla/pull/2008/files/51ca50e3..233b8595

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

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

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

From hgreule at openjdk.org  Sun Feb  1 07:18:29 2026
From: hgreule at openjdk.org (Hannes Greule)
Date: Sun, 1 Feb 2026 07:18:29 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v3]
In-Reply-To: <p_GWL1cU-sn8GU25-z6sme5PqYM1oskbJ1PS2hBtmRA=.6bda9f19-8f27-450e-a3e4-bd9be55b14f3@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
 <p_GWL1cU-sn8GU25-z6sme5PqYM1oskbJ1PS2hBtmRA=.6bda9f19-8f27-450e-a3e4-bd9be55b14f3@github.com>
Message-ID: <Viwc7mlw0t6ZZZJ--P4SLq0ZrS8umH22MRipBtePmEg=.9403db56-6c93-4919-b513-b80e51c5e80b@github.com>

On Sun, 1 Feb 2026 01:34:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> adding some additional regression tests for local proxy variables
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   making the compiler reusable

test/langtools/tools/javac/valhalla/value-objects/LocalProxyVariablesTests.java line 27:

> 25:  * @test
> 26:  * @bug 8180141
> 27:  * @summary Missing entry in LineNumberTable for break statement that jumps out of try-finally

I assume this is a copy-paste leftover?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2008#discussion_r2750660424

From vromero at openjdk.org  Sun Feb  1 13:28:31 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 1 Feb 2026 13:28:31 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v3]
In-Reply-To: <Viwc7mlw0t6ZZZJ--P4SLq0ZrS8umH22MRipBtePmEg=.9403db56-6c93-4919-b513-b80e51c5e80b@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
 <p_GWL1cU-sn8GU25-z6sme5PqYM1oskbJ1PS2hBtmRA=.6bda9f19-8f27-450e-a3e4-bd9be55b14f3@github.com>
 <Viwc7mlw0t6ZZZJ--P4SLq0ZrS8umH22MRipBtePmEg=.9403db56-6c93-4919-b513-b80e51c5e80b@github.com>
Message-ID: <7y7IGNcgmgkAnMcajJn8ObDjYakzIQNkuE76pY6kwzo=.bbde321f-b323-44d3-8f83-0e92550ff88a@github.com>

On Sun, 1 Feb 2026 07:15:59 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   making the compiler reusable
>
> test/langtools/tools/javac/valhalla/value-objects/LocalProxyVariablesTests.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8180141
>> 27:  * @summary Missing entry in LineNumberTable for break statement that jumps out of try-finally
> 
> I assume this is a copy-paste leftover?

oops

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2008#discussion_r2751215752

From vromero at openjdk.org  Sun Feb  1 13:33:11 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 1 Feb 2026 13:33:11 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v4]
In-Reply-To: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
Message-ID: <5Qx67Uwv-2T2fIQOTa0ZtJThcND1Bq7eUDrmUxxQx84=.e1e1b160-d06a-4bc1-aefb-1973ca77b02d@github.com>

> adding some additional regression tests for local proxy variables
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  fixing test annotations

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2008/files
  - new: https://git.openjdk.org/valhalla/pull/2008/files/233b8595..12401ea5

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

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

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

From jsikstro at openjdk.org  Mon Feb  2 09:12:32 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 2 Feb 2026 09:12:32 GMT
Subject: [lworld] RFR: 8376358: [lworld]
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 fails assert(oopDesc::is_oop(obj)) failed: not an oop
In-Reply-To: <bBV6k2Ds0REmRQKyiCDG7pfdRns9hWneC3E0z6qLjEg=.27cb65eb-c551-47f2-8247-30ba919b0127@github.com>
References: <bBV6k2Ds0REmRQKyiCDG7pfdRns9hWneC3E0z6qLjEg=.27cb65eb-c551-47f2-8247-30ba919b0127@github.com>
Message-ID: <wQyuKgz8R220tEwkd0FUEL06Bie7PXGaGHLgsdGpyyE=.94cd1419-e02c-4976-a9d6-c8f36e818a4d@github.com>

On Tue, 27 Jan 2026 21:57:41 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This test failed intermittently likely due to a gap between the array creation and the oop handle creation. Verified with repeated testing.

Looks good.

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

Marked as reviewed by jsikstro (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1986#pullrequestreview-3738161668

From fyang at openjdk.org  Mon Feb  2 09:18:47 2026
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 2 Feb 2026 09:18:47 GMT
Subject: [lworld] RFR: 8376883: [lworld] Only enable
 compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86
Message-ID: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>

Hi,

Please consider this small test-only change.
Seems this test depends on the two optimizations: -XX:+InlineTypePassFieldsAsArgs and -XX:-InlineTypeReturnedAsFields.
It fails without either of them. So it might be more reasonable to only enable it for platforms which implement these
two optimizations.

Verified on linux-aarch64 platform.

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

Commit messages:
 - 8376883: [lworld] Only enable compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86

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

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

From jsikstro at openjdk.org  Mon Feb  2 09:27:33 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 2 Feb 2026 09:27:33 GMT
Subject: [lworld] RFR: 8376813: [lworld] Add print for dummy field reused
 as null-marker [v2]
In-Reply-To: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
References: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
Message-ID: <iCO233rLVT6BsjL_4fomeXfZqse7z2jg0yZJ8sQmRkg=.1bf1cbf4-14c3-4188-b07d-b8507d61809d@github.com>

> Hello,
> 
> Right now it's not clear that the dummy field that is injected into empty inline klasses can be/is reused for the null-marker when looking at the printed layout from -XX:+PrintInlineLayout. I suggest we enhance this print to indicate if the dummy field has been reused for the null-marker.
> 
> I've tested that the added comment in the print is there when nullability is turned on (default), and not there when turned off (`-XX:-UseNullableValueFlattening -XX:-UseNullableNonAtomicValueFlattening`).
> 
> 
> Before:
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 ".empty" B
> 
> After:
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 ".empty" B (reused as null-marker)
> 
> 
> Testing:
> * GHA
> * Oracle's tier1

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  no dummy field in static layout printing

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2001/files
  - new: https://git.openjdk.org/valhalla/pull/2001/files/a94f1bf5..87849f24

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

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

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

From jsikstro at openjdk.org  Mon Feb  2 09:27:36 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 2 Feb 2026 09:27:36 GMT
Subject: [lworld] RFR: 8376813: [lworld] Add print for dummy field reused
 as null-marker [v2]
In-Reply-To: <LlNxEBI9fSfCcmczD3DSTgktWMgACveo4YgqcoHtszA=.8b886d0c-36c0-4b72-b63a-0d48e6636b8c@github.com>
References: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
 <LlNxEBI9fSfCcmczD3DSTgktWMgACveo4YgqcoHtszA=.8b886d0c-36c0-4b72-b63a-0d48e6636b8c@github.com>
Message-ID: <YUfrJdtsCYbTxn0iCEwG2qu4sabiHIKm4287SLFBZb8=.518aa47c-b97a-41f2-905c-a1fecf1b57c4@github.com>

On Fri, 30 Jan 2026 22:02:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   no dummy field in static layout printing
>
> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1587:
> 
>> 1585:     _layout->print(&st, false, _super_klass, _inline_layout_info_array, dummy_field_is_reused_as_null_marker);
>> 1586:     st.print_cr("Static fields:");
>> 1587:     _static_layout->print(&st, true, nullptr, _inline_layout_info_array, dummy_field_is_reused_as_null_marker);
> 
> Does the static layout ever have a dummy field? I would have anticipated this to be simply `false`.

No, the dummy field is nonstatic. I'll change the _static_layout print to use `false` instead.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2001#discussion_r2753353383

From phubner at openjdk.org  Mon Feb  2 09:34:37 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 2 Feb 2026 09:34:37 GMT
Subject: [lworld] RFR: 8376883: [lworld] Only enable
 compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86
In-Reply-To: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
References: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
Message-ID: <K1JUIlsv91c4al9AFkVW06jCH1nV97O9IMB0sLbmEAM=.c2c248db-9a38-4d68-9231-c48b3db895b0@github.com>

On Mon, 2 Feb 2026 09:09:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi,
> 
> Please consider this small test-only change.
> Seems this test depends on the two optimizations: -XX:+InlineTypePassFieldsAsArgs and -XX:-InlineTypeReturnedAsFields.
> It fails without either of them. So it might be more reasonable to only enable it for platforms which implement these
> two optimizations.
> 
> Verified on linux-aarch64 platform.

Thanks for the patch! Looks good to me, but I think it'd be good to get a compiler expert to take a look as well.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2009#pullrequestreview-3738258481

From phubner at openjdk.org  Mon Feb  2 09:34:40 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 2 Feb 2026 09:34:40 GMT
Subject: [lworld] RFR: 8372745: [lworld] Fatal error in native method when
 running java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java with
 --enable-preview
In-Reply-To: <NBM2k-VoxXySryQLvdfZRv0R7sCGajUmVUMZKGtNuVc=.f6c9bcc8-71f7-4d8a-bf09-6c0703b9c034@github.com>
References: <NBM2k-VoxXySryQLvdfZRv0R7sCGajUmVUMZKGtNuVc=.f6c9bcc8-71f7-4d8a-bf09-6c0703b9c034@github.com>
Message-ID: <1EogjPMJ6WvZu-fbM9zLHv3ECXO0TiBltyA0N4TRujw=.9e2ffe5b-6dae-4279-b7bf-6de2289f4939@github.com>

On Fri, 30 Jan 2026 14:17:15 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The test no longer fails with `--enable-preview`, this PR removes it from the problem list.
> 
> Testing: running the test locally 100x and 20x on Linux (x64, AArch64), macOS (AArch64, x64), Windows (x64).

Thanks for the reviews Chen and Lois! I think indeed it might have been something upstream.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2000#issuecomment-3833978406

From phubner at openjdk.org  Mon Feb  2 09:34:41 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 2 Feb 2026 09:34:41 GMT
Subject: [lworld] Integrated: 8372745: [lworld] Fatal error in native method
 when running java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java with
 --enable-preview
In-Reply-To: <NBM2k-VoxXySryQLvdfZRv0R7sCGajUmVUMZKGtNuVc=.f6c9bcc8-71f7-4d8a-bf09-6c0703b9c034@github.com>
References: <NBM2k-VoxXySryQLvdfZRv0R7sCGajUmVUMZKGtNuVc=.f6c9bcc8-71f7-4d8a-bf09-6c0703b9c034@github.com>
Message-ID: <aT0CtB0yNQqw3kdhkFyyp8r_yjd9UqIvatC5D6G7DFA=.9f6f31eb-8cde-4c3d-9844-ab7b7e6baf99@github.com>

On Fri, 30 Jan 2026 14:17:15 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The test no longer fails with `--enable-preview`, this PR removes it from the problem list.
> 
> Testing: running the test locally 100x and 20x on Linux (x64, AArch64), macOS (AArch64, x64), Windows (x64).

This pull request has now been integrated.

Changeset: d82abf03
Author:    Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d82abf0320dba498e931c68cc117ace36db343d5
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8372745: [lworld] Fatal error in native method when running java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java with --enable-preview

Reviewed-by: liach, lfoltan

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

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

From jsikstro at openjdk.org  Mon Feb  2 09:53:04 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 2 Feb 2026 09:53:04 GMT
Subject: [lworld] RFR: 8376221: [lworld] Do not store array of
 InlineLayoutInfo for all InstanceKlasses [v6]
In-Reply-To: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
References: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
Message-ID: <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>

> Hello,
> 
> Please refer to the JBS issue for a more detailed description of the background of this change. In summary, I suggest we only keep the array of InlineLayoutInfo for InstanceKlasses which need it, which are Klasses that have fields that have been inlined.
> 
> To make the transition to this easier, I suggest we change the following properties in FieldLayoutBuilder: 
> 
> _has_inline_type_fields
> _has_flattening_information
> 
> to
> 
> _has_inlineable_fields
> _has_inlined_fields
> 
> The `_has_inlineable_fields` property is only used for printing and `_has_inlined_fields` is the property we expose out to the ClassFileParser, telling us that this class has inlined fields, so the array of InlineLayoutInfo must be "preserved" and is possible to read from. Hence, the array is now only safe to access if `InstanceKlass::has_inlined_fields` is true, or simply if the actual field being accessed is flat (`fieldDescriptor::is_flat`).
> 
> I only found one place (in ciReplay.cpp) where we access the array of InlineLayoutInfo even though we might not have any inlined fields and only fields that are inlineable. I've changed this to use the normal "reference" path for fields that aren't flat.
> 
> Testing:
> * Oracle's tier1-5, hotspot_valhalla and jdk_valhalla

Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:

 - Move InlineKlass::cast() to callers
 - Add abstract check to field_is_inlineable

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1966/files
  - new: https://git.openjdk.org/valhalla/pull/1966/files/b934da63..cb80bac9

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

  Stats: 11 lines in 3 files changed: 2 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1966.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1966/head:pull/1966

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

From jsikstro at openjdk.org  Mon Feb  2 09:53:08 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 2 Feb 2026 09:53:08 GMT
Subject: [lworld] RFR: 8376221: [lworld] Do not store array of
 InlineLayoutInfo for all InstanceKlasses [v5]
In-Reply-To: <SHhAPtxLo6z8UJot_XMO59qy1X9XuCZH6XthovSYrsM=.543c7eb3-2539-4bfc-983b-215f2d68a9d4@github.com>
References: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
 <OAfTTMaqXJlA8ef6deCARJNCSinFgLKKoN6kntzJHtE=.569cf41f-c812-4eb5-b64c-d84cb36dab37@github.com>
 <SHhAPtxLo6z8UJot_XMO59qy1X9XuCZH6XthovSYrsM=.543c7eb3-2539-4bfc-983b-215f2d68a9d4@github.com>
Message-ID: <LglNInual-xwLf_F2HlviAWzU0GMb3b5FSGOgAKKVpw=.e6e71950-d441-4f80-9781-7994fdeae4b5@github.com>

On Thu, 29 Jan 2026 22:00:25 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Joel Sikstr?m 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 11 additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' into JDK-8376221_inlinelayoutinfo_array_optimization
>>  - LayoutKind assertion for flat fields
>>  - Remove mention of 'warning' in comment
>>  - Exception check should really be an assert
>>  - Move inlineable check to static helper
>>  - Comment for second CLEAR_PENDING_EXCEPTION
>>  - Clear exception before setting inline klass
>>  - Split assert in field sorting methods
>>  - IOOB assert message
>>  - InstanceKlass instead of Klass for set_inline_layout_info_klass
>>  - ... and 1 more: https://git.openjdk.org/valhalla/compare/a9b993c8...b934da63
>
> src/hotspot/share/classfile/classFileParser.cpp line 6396:
> 
>> 6394: }
>> 6395: 
>> 6396: void ClassFileParser::set_inline_layout_info_klass(int field_index, InstanceKlass* klass, TRAPS) {
> 
> This method could take an InlineKlass* argument instead of an InstanceKlass* argument, because InlineLayoutInfo can only store information about flat value fields.

Sure, I'll move the `InlineKlass::cast()` from insdide the method to the callers instead.

> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 111:
> 
>> 109:       ili != nullptr &&
>> 110:       ili->adr_at((int)fieldinfo.index())->klass() != nullptr &&
>> 111:       !ili->adr_at((int)fieldinfo.index())->klass()->is_identity_class()) {
> 
> To be inlineable, the class should not be abstract.
> 
> !ili->adr_at((int)fieldinfo.index())->klass()->is_abstract()
> 
> would exclude both abstract value classes and interfaces.

Yes! I'll append that to the checks.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1966#discussion_r2753463390
PR Review Comment: https://git.openjdk.org/valhalla/pull/1966#discussion_r2753463575

From phubner at openjdk.org  Mon Feb  2 10:58:24 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 2 Feb 2026 10:58:24 GMT
Subject: [lworld] RFR: 8376813: [lworld] Add print for dummy field reused
 as null-marker [v2]
In-Reply-To: <iCO233rLVT6BsjL_4fomeXfZqse7z2jg0yZJ8sQmRkg=.1bf1cbf4-14c3-4188-b07d-b8507d61809d@github.com>
References: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
 <iCO233rLVT6BsjL_4fomeXfZqse7z2jg0yZJ8sQmRkg=.1bf1cbf4-14c3-4188-b07d-b8507d61809d@github.com>
Message-ID: <nEB3XhTr392Dd0ptl9XZKdokgf5sSUIffuCAPLTgyzs=.5c52d1d3-7121-424b-b458-6dabf42178f4@github.com>

On Mon, 2 Feb 2026 09:27:33 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Right now it's not clear that the dummy field that is injected into empty inline klasses can be/is reused for the null-marker when looking at the printed layout from -XX:+PrintInlineLayout. I suggest we enhance this print to indicate if the dummy field has been reused for the null-marker.
>> 
>> I've tested that the added comment in the print is there when nullability is turned on (default), and not there when turned off (`-XX:-UseNullableValueFlattening -XX:-UseNullableNonAtomicValueFlattening`).
>> 
>> 
>> Before:
>> Instance fields:
>>  @0 RESERVED 12/-
>>  @12 REGULAR 1/1 ".empty" B
>> 
>> After:
>> Instance fields:
>>  @0 RESERVED 12/-
>>  @12 REGULAR 1/1 ".empty" B (reused as null-marker)
>> 
>> 
>> Testing:
>> * GHA
>> * Oracle's tier1
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no dummy field in static layout printing

Thanks for the changes, this makes debugging and developing a lot easier. One thing that came to mind is that we have a bunch of flat array specific printing logic in e.g. `FlatArrayKlass::oop_print_value_on`. As a possible extension, would we ever want to convey such information in the array itself, rather than the field? For example when debug-printing the human-version of the array header to indicate the null marker is reused as the dummy field (when applicable)?

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2001#pullrequestreview-3738689607

From chagedorn at openjdk.org  Mon Feb  2 11:55:13 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 2 Feb 2026 11:55:13 GMT
Subject: [lworld] Integrated: 8376890: [lworld] Compiler replay crashes when
 class cannot be loaded after JDK-8375548
Message-ID: <eI5pa4csqMbvBEjr9iELfjrSIKaXw7ElZwg2nV0Ff2A=.7144b3af-6b09-448c-8752-54a6972e852d@github.com>

[JDK-8375548](https://bugs.openjdk.org/browse/JDK-8375548) added support for compiler replay but only tested with cases where classes can actually be loaded. When some classes cannot be loaded (for example, due to missing class files), we crash with a null pointer when run with `+ReplayIgnoreInitErrors`: `parse_klass()` returns `null` for non-loadable classes. Then, we access it with `k->is_objArray_klass()` without checking for null and we crash. This patch adds a simple null-check to fix the problem.

Thanks,
Christian

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

Commit messages:
 - 8376890: [lworld] Compiler replay crashes when class cannot be loaded after JDK-8375548

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

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

From thartmann at openjdk.org  Mon Feb  2 11:55:14 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 2 Feb 2026 11:55:14 GMT
Subject: [lworld] Integrated: 8376890: [lworld] Compiler replay crashes
 when class cannot be loaded after JDK-8375548
In-Reply-To: <eI5pa4csqMbvBEjr9iELfjrSIKaXw7ElZwg2nV0Ff2A=.7144b3af-6b09-448c-8752-54a6972e852d@github.com>
References: <eI5pa4csqMbvBEjr9iELfjrSIKaXw7ElZwg2nV0Ff2A=.7144b3af-6b09-448c-8752-54a6972e852d@github.com>
Message-ID: <cpf5lgMhNmREJdxKA51csOXKo32PvKebtv1lPvfOuuE=.7fb48d6b-5e0d-41dd-ad78-445a94923bbc@github.com>

On Mon, 2 Feb 2026 11:48:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8375548](https://bugs.openjdk.org/browse/JDK-8375548) added support for compiler replay but only tested with cases where classes can actually be loaded. When some classes cannot be loaded (for example, due to missing class files), we crash with a null pointer when run with `+ReplayIgnoreInitErrors`: `parse_klass()` returns `null` for non-loadable classes. Then, we access it with `k->is_objArray_klass()` without checking for null and we crash. This patch adds a simple null-check to fix the problem.
> 
> Thanks,
> Christian

Looks good and trivial.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2010#pullrequestreview-3738936386

From chagedorn at openjdk.org  Mon Feb  2 11:55:15 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 2 Feb 2026 11:55:15 GMT
Subject: [lworld] Integrated: 8376890: [lworld] Compiler replay crashes
 when class cannot be loaded after JDK-8375548
In-Reply-To: <eI5pa4csqMbvBEjr9iELfjrSIKaXw7ElZwg2nV0Ff2A=.7144b3af-6b09-448c-8752-54a6972e852d@github.com>
References: <eI5pa4csqMbvBEjr9iELfjrSIKaXw7ElZwg2nV0Ff2A=.7144b3af-6b09-448c-8752-54a6972e852d@github.com>
Message-ID: <7AJED5BtC9Q5yfzIK5LAmsU8_7ATpKvDgfDbHMnqCBU=.21cda543-1e18-40fe-a4d7-939b90158ae8@github.com>

On Mon, 2 Feb 2026 11:48:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8375548](https://bugs.openjdk.org/browse/JDK-8375548) added support for compiler replay but only tested with cases where classes can actually be loaded. When some classes cannot be loaded (for example, due to missing class files), we crash with a null pointer when run with `+ReplayIgnoreInitErrors`: `parse_klass()` returns `null` for non-loadable classes. Then, we access it with `k->is_objArray_klass()` without checking for null and we crash. This patch adds a simple null-check to fix the problem.
> 
> Thanks,
> Christian

Thanks Tobias for your quick review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2010#issuecomment-3834664371

From chagedorn at openjdk.org  Mon Feb  2 11:55:16 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 2 Feb 2026 11:55:16 GMT
Subject: [lworld] Integrated: 8376890: [lworld] Compiler replay crashes when
 class cannot be loaded after JDK-8375548
In-Reply-To: <eI5pa4csqMbvBEjr9iELfjrSIKaXw7ElZwg2nV0Ff2A=.7144b3af-6b09-448c-8752-54a6972e852d@github.com>
References: <eI5pa4csqMbvBEjr9iELfjrSIKaXw7ElZwg2nV0Ff2A=.7144b3af-6b09-448c-8752-54a6972e852d@github.com>
Message-ID: <KMQZ1HyDgbK2OIvo7S3ik3aBtFu5dkVwbjRQqDaV_eo=.0b5b2635-e93e-46f3-bd51-bf0e0d4dcd9e@github.com>

On Mon, 2 Feb 2026 11:48:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8375548](https://bugs.openjdk.org/browse/JDK-8375548) added support for compiler replay but only tested with cases where classes can actually be loaded. When some classes cannot be loaded (for example, due to missing class files), we crash with a null pointer when run with `+ReplayIgnoreInitErrors`: `parse_klass()` returns `null` for non-loadable classes. Then, we access it with `k->is_objArray_klass()` without checking for null and we crash. This patch adds a simple null-check to fix the problem.
> 
> Thanks,
> Christian

This pull request has now been integrated.

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

8376890: [lworld] Compiler replay crashes when class cannot be loaded after JDK-8375548

Reviewed-by: thartmann

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

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

From phubner at openjdk.org  Mon Feb  2 12:21:53 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 2 Feb 2026 12:21:53 GMT
Subject: [lworld] RFR: 8376358: [lworld]
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 fails assert(oopDesc::is_oop(obj)) failed: not an oop
In-Reply-To: <bBV6k2Ds0REmRQKyiCDG7pfdRns9hWneC3E0z6qLjEg=.27cb65eb-c551-47f2-8247-30ba919b0127@github.com>
References: <bBV6k2Ds0REmRQKyiCDG7pfdRns9hWneC3E0z6qLjEg=.27cb65eb-c551-47f2-8247-30ba919b0127@github.com>
Message-ID: <1ykhBY-0eHmkPntqr2Z5TDnfNEW8VChljdzXHTolwmQ=.75a28355-4fcf-4e34-87c1-a8803f05669e@github.com>

On Tue, 27 Jan 2026 21:57:41 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This test failed intermittently likely due to a gap between the array creation and the oop handle creation. Verified with repeated testing.

Thank you.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1986#pullrequestreview-3739062959

From thartmann at openjdk.org  Mon Feb  2 14:04:38 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 2 Feb 2026 14:04:38 GMT
Subject: [lworld] RFR: 8375086: [lworld] Implicit exception handling in
 inline-cache check is broken
Message-ID: <94iZZH5-Ea9ZHlApHvhBHPlkLZWqvaEBSVrxCTJ06yw=.1d1dbf65-d148-4e5e-ae27-1d0cc4ed5bc7@github.com>

We crash with a `SIGSEGV` instead of throwing a `NullPointerException` when passing a `null` receiver through an inline cache'd interface call site because the implicit null check that happens when doing the receiver type check in the unverified entry point of the nmethod is not working properly.

When `SharedRuntime::continuation_for_implicit_exception` checks where the `IMPLICIT_NULL` exception came from, it does not recognize the entry point:
https://github.com/openjdk/valhalla/blob/55c80fedfcee5d3b113cdf38d64c1bcac8632c9a/src/hotspot/share/runtime/sharedRuntime.cpp#L1021-L1028

However, with the scalarized calling convention, we have two unverified entry points (`verified_entry_point` and `verified_inline_entry_point`). Both need to be handled in `nmethod::inlinecache_check_contains`.

Thanks,
Tobias

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

Commit messages:
 - JDK-8375086

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

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

From thartmann at openjdk.org  Mon Feb  2 14:06:18 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 2 Feb 2026 14:06:18 GMT
Subject: [lworld] RFR: 8376883: [lworld] Only enable
 compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86
In-Reply-To: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
References: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
Message-ID: <OBaKvfwAEcGSgBPSdUO-FdYExGMGstbCbP1XF5oPv6Q=.c0eddeb0-0604-4beb-997e-9c582e580470@github.com>

On Mon, 2 Feb 2026 09:09:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi,
> 
> Please consider this small test-only change.
> Seems this test depends on the two optimizations: -XX:+InlineTypePassFieldsAsArgs and -XX:-InlineTypeReturnedAsFields.
> It fails without either of them. So it might be more reasonable to only enable it for platforms which implement these
> two optimizations.
> 
> Verified on linux-aarch64 platform.

Looks good to me too. Thanks!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2009#pullrequestreview-3739609746

From chagedorn at openjdk.org  Mon Feb  2 14:09:31 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 2 Feb 2026 14:09:31 GMT
Subject: [lworld] RFR: 8375086: [lworld] Implicit exception handling in
 inline-cache check is broken
In-Reply-To: <94iZZH5-Ea9ZHlApHvhBHPlkLZWqvaEBSVrxCTJ06yw=.1d1dbf65-d148-4e5e-ae27-1d0cc4ed5bc7@github.com>
References: <94iZZH5-Ea9ZHlApHvhBHPlkLZWqvaEBSVrxCTJ06yw=.1d1dbf65-d148-4e5e-ae27-1d0cc4ed5bc7@github.com>
Message-ID: <hFjggQsHtxFZGICDkJpoas38YyGMJdeh1PyxrlFqRXY=.56539099-4f35-4a92-b7f6-a4bd139f10e8@github.com>

On Mon, 2 Feb 2026 13:58:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We crash with a `SIGSEGV` instead of throwing a `NullPointerException` when passing a `null` receiver through an inline cache'd interface call site because the implicit null check that happens when doing the receiver type check in the unverified entry point of the nmethod is not working properly.
> 
> When `SharedRuntime::continuation_for_implicit_exception` checks where the `IMPLICIT_NULL` exception came from, it does not recognize the entry point:
> https://github.com/openjdk/valhalla/blob/55c80fedfcee5d3b113cdf38d64c1bcac8632c9a/src/hotspot/share/runtime/sharedRuntime.cpp#L1021-L1028
> 
> However, with the scalarized calling convention, we have two unverified entry points (`verified_entry_point` and `verified_inline_entry_point`). Both need to be handled in `nmethod::inlinecache_check_contains`.
> 
> Thanks,
> Tobias

That looks good to me.

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2011#pullrequestreview-3739625348

From thartmann at openjdk.org  Mon Feb  2 14:09:32 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 2 Feb 2026 14:09:32 GMT
Subject: [lworld] RFR: 8375086: [lworld] Implicit exception handling in
 inline-cache check is broken
In-Reply-To: <94iZZH5-Ea9ZHlApHvhBHPlkLZWqvaEBSVrxCTJ06yw=.1d1dbf65-d148-4e5e-ae27-1d0cc4ed5bc7@github.com>
References: <94iZZH5-Ea9ZHlApHvhBHPlkLZWqvaEBSVrxCTJ06yw=.1d1dbf65-d148-4e5e-ae27-1d0cc4ed5bc7@github.com>
Message-ID: <rL8HTDLbE_CQJ3mxnYz8V9vCxzba7WSkwUJZ8VdWeQM=.7e9674f5-f95c-4fae-b785-9b52f52c13a2@github.com>

On Mon, 2 Feb 2026 13:58:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We crash with a `SIGSEGV` instead of throwing a `NullPointerException` when passing a `null` receiver through an inline cache'd interface call site because the implicit null check that happens when doing the receiver type check in the unverified entry point of the nmethod is not working properly.
> 
> When `SharedRuntime::continuation_for_implicit_exception` checks where the `IMPLICIT_NULL` exception came from, it does not recognize the entry point:
> https://github.com/openjdk/valhalla/blob/55c80fedfcee5d3b113cdf38d64c1bcac8632c9a/src/hotspot/share/runtime/sharedRuntime.cpp#L1021-L1028
> 
> However, with the scalarized calling convention, we have two unverified entry points (`verified_entry_point` and `verified_inline_entry_point`). Both need to be handled in `nmethod::inlinecache_check_contains`.
> 
> Thanks,
> Tobias

Thanks for the quick review Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2011#issuecomment-3835345631

From fparain at openjdk.org  Mon Feb  2 14:25:49 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 2 Feb 2026 14:25:49 GMT
Subject: [lworld] RFR: 8376135: [lworld] Add JIT support for
 NULLABLE_NON_ATOMIC_FLAT layout [v8]
In-Reply-To: <WjEzkxFeUiOlbS-15uevp96qWbPy2TeCDGb7SmhRMMM=.dd08be40-7020-4ddb-ae5c-e8baa416ecc4@github.com>
References: <HSX1UCudQNMpzr0NPJekMKtz70WbNFDnpQ5Q3-EGDh8=.32c24056-dd89-49cd-bbba-92c21eb18bfc@github.com>
 <WjEzkxFeUiOlbS-15uevp96qWbPy2TeCDGb7SmhRMMM=.dd08be40-7020-4ddb-ae5c-e8baa416ecc4@github.com>
Message-ID: <ie6DjjH8V6qQn4hOEr3cGRoJfnjVxjq5-6nWUuhMGIM=.eba75c47-245d-49c5-84f5-adaab4ea5aa6@github.com>

On Sat, 31 Jan 2026 06:09:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR implements the support of `NULLABLE_NON_ATOMIC_FLAT` layout in the JITs. There is nothing to do in C2. In C1, I need to implement loading/storing nullable value of a non-atomic field.
>> 
>> The test `TestValueClasses` is failing with `-XX:-TieredCompilation`, which I suspect is due to the substitutability test handling padding bytes incorrectly.
>> 
>> Please kindly review what there are for now, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'lworld' into nullablenonstatic
>  - Remove Strict
>  - Merge branch 'lworld' into nullablenonstatic
>  - Adjust test, add comments and examples
>  - add assert
>  - remove unused variable
>  - no_null_marker
>  - rename null_free in InlineTypeNode::initialize_fields to has_null_marker
>  - Fix packing/unpacking adapters, fix some miscelaneous issues, address comment
>  - Support NULLABLE_NON_ATOMIC in the JITs

Looks good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1970#pullrequestreview-3739731420

From fparain at openjdk.org  Mon Feb  2 14:33:21 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 2 Feb 2026 14:33:21 GMT
Subject: [lworld] RFR: 8376221: [lworld] Do not store array of
 InlineLayoutInfo for all InstanceKlasses [v6]
In-Reply-To: <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>
References: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
 <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>
Message-ID: <_A81AAlPwiEoxCRWDcXoC-T5WeacZas1nUFvI7SpDJo=.504ad2bd-0f9c-4736-98bd-e144d0848053@github.com>

On Mon, 2 Feb 2026 09:53:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Please refer to the JBS issue for a more detailed description of the background of this change. In summary, I suggest we only keep the array of InlineLayoutInfo for InstanceKlasses which need it, which are Klasses that have fields that have been inlined.
>> 
>> To make the transition to this easier, I suggest we change the following properties in FieldLayoutBuilder: 
>> 
>> _has_inline_type_fields
>> _has_flattening_information
>> 
>> to
>> 
>> _has_inlineable_fields
>> _has_inlined_fields
>> 
>> The `_has_inlineable_fields` property is only used for printing and `_has_inlined_fields` is the property we expose out to the ClassFileParser, telling us that this class has inlined fields, so the array of InlineLayoutInfo must be "preserved" and is possible to read from. Hence, the array is now only safe to access if `InstanceKlass::has_inlined_fields` is true, or simply if the actual field being accessed is flat (`fieldDescriptor::is_flat`).
>> 
>> I only found one place (in ciReplay.cpp) where we access the array of InlineLayoutInfo even though we might not have any inlined fields and only fields that are inlineable. I've changed this to use the normal "reference" path for fields that aren't flat.
>> 
>> Testing:
>> * Oracle's tier1-5, hotspot_valhalla and jdk_valhalla
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move InlineKlass::cast() to callers
>  - Add abstract check to field_is_inlineable

Looks good to me.
Thank you for this cleanup.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1966#pullrequestreview-3739779064

From thartmann at openjdk.org  Mon Feb  2 14:41:48 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 2 Feb 2026 14:41:48 GMT
Subject: [lworld] RFR: 8376135: [lworld] Add JIT support for
 NULLABLE_NON_ATOMIC_FLAT layout [v8]
In-Reply-To: <WjEzkxFeUiOlbS-15uevp96qWbPy2TeCDGb7SmhRMMM=.dd08be40-7020-4ddb-ae5c-e8baa416ecc4@github.com>
References: <HSX1UCudQNMpzr0NPJekMKtz70WbNFDnpQ5Q3-EGDh8=.32c24056-dd89-49cd-bbba-92c21eb18bfc@github.com>
 <WjEzkxFeUiOlbS-15uevp96qWbPy2TeCDGb7SmhRMMM=.dd08be40-7020-4ddb-ae5c-e8baa416ecc4@github.com>
Message-ID: <WmocfTFmrxAc076PqTi4Pl-UpoP_HFRBZICmjYzYOAI=.0e1ddc9e-9cfa-4d33-8a58-0759c4576327@github.com>

On Sat, 31 Jan 2026 06:09:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR implements the support of `NULLABLE_NON_ATOMIC_FLAT` layout in the JITs. There is nothing to do in C2. In C1, I need to implement loading/storing nullable value of a non-atomic field.
>> 
>> The test `TestValueClasses` is failing with `-XX:-TieredCompilation`, which I suspect is due to the substitutability test handling padding bytes incorrectly.
>> 
>> Please kindly review what there are for now, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'lworld' into nullablenonstatic
>  - Remove Strict
>  - Merge branch 'lworld' into nullablenonstatic
>  - Adjust test, add comments and examples
>  - add assert
>  - remove unused variable
>  - no_null_marker
>  - rename null_free in InlineTypeNode::initialize_fields to has_null_marker
>  - Fix packing/unpacking adapters, fix some miscelaneous issues, address comment
>  - Support NULLABLE_NON_ATOMIC in the JITs

Nice comments!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1970#pullrequestreview-3739827679

From qamai at openjdk.org  Mon Feb  2 15:32:06 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Feb 2026 15:32:06 GMT
Subject: [lworld] RFR: 8376135: [lworld] Add JIT support for
 NULLABLE_NON_ATOMIC_FLAT layout [v8]
In-Reply-To: <WjEzkxFeUiOlbS-15uevp96qWbPy2TeCDGb7SmhRMMM=.dd08be40-7020-4ddb-ae5c-e8baa416ecc4@github.com>
References: <HSX1UCudQNMpzr0NPJekMKtz70WbNFDnpQ5Q3-EGDh8=.32c24056-dd89-49cd-bbba-92c21eb18bfc@github.com>
 <WjEzkxFeUiOlbS-15uevp96qWbPy2TeCDGb7SmhRMMM=.dd08be40-7020-4ddb-ae5c-e8baa416ecc4@github.com>
Message-ID: <k6wO3bLJbADlgtAPYKXO56Rf4s1J6yn2IpA9_vwFewM=.d1ad2dc2-17d5-41e0-ac59-e580bbf24adc@github.com>

On Sat, 31 Jan 2026 06:09:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR implements the support of `NULLABLE_NON_ATOMIC_FLAT` layout in the JITs. There is nothing to do in C2. In C1, I need to implement loading/storing nullable value of a non-atomic field.
>> 
>> The test `TestValueClasses` is failing with `-XX:-TieredCompilation`, which I suspect is due to the substitutability test handling padding bytes incorrectly.
>> 
>> Please kindly review what there are for now, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'lworld' into nullablenonstatic
>  - Remove Strict
>  - Merge branch 'lworld' into nullablenonstatic
>  - Adjust test, add comments and examples
>  - add assert
>  - remove unused variable
>  - no_null_marker
>  - rename null_free in InlineTypeNode::initialize_fields to has_null_marker
>  - Fix packing/unpacking adapters, fix some miscelaneous issues, address comment
>  - Support NULLABLE_NON_ATOMIC in the JITs

Thanks a lot for your reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1970#issuecomment-3835869422

From qamai at openjdk.org  Mon Feb  2 15:32:07 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Feb 2026 15:32:07 GMT
Subject: [lworld] Integrated: 8376135: [lworld] Add JIT support for
 NULLABLE_NON_ATOMIC_FLAT layout
In-Reply-To: <HSX1UCudQNMpzr0NPJekMKtz70WbNFDnpQ5Q3-EGDh8=.32c24056-dd89-49cd-bbba-92c21eb18bfc@github.com>
References: <HSX1UCudQNMpzr0NPJekMKtz70WbNFDnpQ5Q3-EGDh8=.32c24056-dd89-49cd-bbba-92c21eb18bfc@github.com>
Message-ID: <6RLbvhKPmx9qvX9aNYHykkCuV677D_AyyHAdIdB2jp8=.2f14389b-0513-459b-b0e8-dc7122258626@github.com>

On Mon, 26 Jan 2026 14:01:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This PR implements the support of `NULLABLE_NON_ATOMIC_FLAT` layout in the JITs. There is nothing to do in C2. In C1, I need to implement loading/storing nullable value of a non-atomic field.
> 
> The test `TestValueClasses` is failing with `-XX:-TieredCompilation`, which I suspect is due to the substitutability test handling padding bytes incorrectly.
> 
> Please kindly review what there are for now, thanks a lot.

This pull request has now been integrated.

Changeset: 2ad3ce16
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2ad3ce1646bb5c717239f683686dd1034a9340c1
Stats:     268 lines in 22 files changed: 150 ins; 34 del; 84 mod

8376135: [lworld] Add JIT support for NULLABLE_NON_ATOMIC_FLAT layout

Reviewed-by: thartmann, fparain

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

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

From qamai at openjdk.org  Mon Feb  2 15:51:47 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Feb 2026 15:51:47 GMT
Subject: [lworld] RFR: 8376059: [lworld] Aarch64: StoreLSpecial with 1 oop does
 not save register in pre-barrier
Message-ID: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>

Hi,

Many thanks to @stefank for finding the issue and helping investigating it. This PR fixes a couple of issues:

- `g1StoreLSpecialOneOop` does not save `mem` and `src` during the GC pre-barrier, this risks clobber these values, which may lead to crashes or memory corruption when doing the store instruction.
- It seems that the value passed to the post-barrier should be an uncompressed oop, this requires us to decode the narrow oop instead of simply zero-extending it.
- Relax the restriction on the `src` register to be an arbitrary register.
- Split the rule into 2 so that we can avoid cloberring an additional register when the offset of the oop inside the payload is 0.

Testing:
- [x] tier1, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
- [ ] tier1-4, valhalla-comp-stress, linux-aarch64
- [ ] tier1-4, valhalla-comp-stress, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`

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

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

Commit messages:
 - Missing preserve register for g1StoreLSpecialOneOop

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

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

From qamai at openjdk.org  Mon Feb  2 16:38:57 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Feb 2026 16:38:57 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v2]
In-Reply-To: <o04pcdsUHYUmnrBXoGMAw_-7HD4jF0QTKUb3SVVGSjM=.4127cdaf-15e5-48ce-8506-893fa17f22e2@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <o04pcdsUHYUmnrBXoGMAw_-7HD4jF0QTKUb3SVVGSjM=.4127cdaf-15e5-48ce-8506-893fa17f22e2@github.com>
Message-ID: <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>

On Wed, 28 Jan 2026 09:19:18 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Some code added by [JDK-8372700](https://bugs.openjdk.org/browse/JDK-8372700) can compute the constant value of a field of a (flatten) element in a flat array. We get a crash when the element of the array is known to be `null`, and so the field doesn't exist.
>> 
>> So, let's just check in `ciConstant ciFlatArray::field_value(int index, ciField* field)` whether we get a null constant before interpreting it as a `ciInstance` and trying to retrieve a field from there. This should be enough since a `ciObject` is (directly) derived by `ciNullObject`, `ciInstance` and `ciArray`. Since we are looking up a value of a flat array, an element cannot be a `ciArray` (arrays have identities and can't be contained in a flat array). After looking up whether the flat array element is null, the `obj->as_instance()` cast acts as an assert, should we ever add another derived class from `ciObject`.
>> 
>> In case of a null array element, `field_value` simply returns an invalid `ciConstant`.
>> 
>> Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks good.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - Details
>  - exception handling
>  - oops
>  - Also cache correctly whole stable fields
>  - fix comment
>  - Remove debug
>  - ShouldNotReachHere
>  - explicit casts
>  - Clean up
>  - expand_constant

Thanks a lot for working on this, I have a couple of comments.

src/hotspot/share/ci/ciInstance.cpp line 86:

> 84:         InstanceKlass* holder = InstanceKlass::cast(obj->klass());
> 85:         int index = -1;
> 86:         for (JavaFieldStream fs(holder); !fs.done(); fs.next()) {

My latest PR should include a `_layout_kind` in the `ciField` object, can you use it?

src/hotspot/share/ci/ciInstance.cpp line 95:

> 93:         InlineLayoutInfo* layout_info = holder->inline_layout_info_adr(index);
> 94:         InlineKlass* vk = layout_info->klass();
> 95:         oop res = vk->read_payload_from_addr(obj, offset, layout_info->kind(), THREAD);

It seems to imply that this access is required to be atomic, what if it is a non-atomic field?

src/hotspot/share/ci/ciInstance.cpp line 137:

> 135: // desired field. If we want a sub-field of a flat field, we then extract the field
> 136: // out of the cached copy.
> 137: ciConstant ciInstance::field_value(ciField* field) {

Similarly, what kind of field is expected here, is it a declared field, or a primitive subfield?

src/hotspot/share/ci/ciInstance.cpp line 144:

> 142:   ciInstanceKlass* klass = this->klass()->as_instance_klass();
> 143:   ciField* containing_field;
> 144:   if (field->original_holder() == nullptr) {

Is this branch necessary, I thought `klass->field_index_by_offset` should give the correct result if `field` is not a subfield?

src/hotspot/share/ci/ciInstance.cpp line 154:

> 152:     return ciConstant();
> 153:   }
> 154:   if (field->original_holder() == nullptr) {

I think simply comparing `field` and `containing_field` is enough.

src/hotspot/share/ci/ciInstance.cpp line 175:

> 173: // Extract a field from a value object.
> 174: // This won't cache. Must be used only on cached values.
> 175: ciConstant ciInstance::non_flat_field_value(ciField* field) {

Can you specify which kind of `field` is required here. I would assume this is a declared field that is not a flat field.

src/hotspot/share/ci/ciInstanceKlass.cpp line 440:

> 438: }
> 439: 
> 440: int ciInstanceKlass::field_index_by_offset(int offset) {

Why is assert needs removing?

src/hotspot/share/opto/compile.cpp line 2106:

> 2104:       ciInstance* loaded_from = nullptr;
> 2105:       if (FoldStableValues) {
> 2106:         const TypeOopPtr* base_type = igvn.type(loadn->base())->isa_oopptr();

Normally, `isa_...` methods are only used if we want to null check it, otherwise, use the corresponding `is_...` method.

src/hotspot/share/opto/compile.cpp line 2125:

> 2123:         } else if (oop != nullptr && oop->is_array()) {
> 2124:           ciArray* array = oop->as_array();
> 2125:           ciConstant elt = array->element_value_by_offset(off);

IIUC, `off` can be `Type::OffsetBot` here, I think it would be better to handle it here because it is an implementation detail that should not be visible to `ci`.

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

PR Review: https://git.openjdk.org/valhalla/pull/1923#pullrequestreview-3740519059
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755233617
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755235862
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755208953
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755222711
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755226019
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755200089
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755239944
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755166332
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2755181723

From phubner at openjdk.org  Mon Feb  2 16:51:00 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 2 Feb 2026 16:51:00 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method
Message-ID: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>

Hi all,

This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.

Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

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

Commit messages:
 - Years
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
 - substitutability contract changed
 - Legacy handling in ProcessHandleImpl
 - typo
 - Test flags
 - Dead stuff
 - Merge branch 'JDK-8372954' of github.com:Arraying/valhalla into JDK-8372954
 - Merge pull request #1 from liach/fix/remove-old-substitutability
 - Nuke old substitutability
 - ... and 1 more: https://git.openjdk.org/valhalla/compare/2ad3ce16...5e3f8d13

Changes: https://git.openjdk.org/valhalla/pull/2012/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372954
  Stats: 1789 lines in 25 files changed: 4 ins; 1734 del; 51 mod
  Patch: https://git.openjdk.org/valhalla/pull/2012.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2012/head:pull/2012

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

From qamai at openjdk.org  Mon Feb  2 17:23:39 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Feb 2026 17:23:39 GMT
Subject: [lworld] RFR: 8376059: [lworld] Aarch64: StoreLSpecial with 1 oop
 does not save register in pre-barrier [v2]
In-Reply-To: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
References: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
Message-ID: <FJQgSBJcWCcy7EyfOqSKNau1h9dprlCkORdH0pQLrDg=.67fa163e-8a7e-4936-9e62-b40546d3070f@github.com>

> Hi,
> 
> Many thanks to @stefank for finding the issue and helping investigating it. This PR fixes a couple of issues:
> 
> - `g1StoreLSpecialOneOop` does not save `mem` and `src` during the GC pre-barrier, this risks clobber these values, which may lead to crashes or memory corruption when doing the store instruction.
> - It seems that the value passed to the post-barrier should be an uncompressed oop, this requires us to decode the narrow oop instead of simply zero-extending it.
> - Relax the restriction on the `src` register to be an arbitrary register.
> - Split the rule into 2 so that we can avoid cloberring an additional register when the offset of the oop inside the payload is 0.
> 
> Testing:
> - [x] tier1, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
> - [x] tier1-4, valhalla-comp-stress, linux-aarch64
> - [x] tier1-4, valhalla-comp-stress, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
> 
> 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:

 - Saving the register in the slow path instead
 - recompute tmp4 instead of saving it

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2013/files
  - new: https://git.openjdk.org/valhalla/pull/2013/files/0f61cdc6..fb475fc6

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

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

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

From phubner at openjdk.org  Mon Feb  2 17:24:48 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 2 Feb 2026 17:24:48 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v2]
In-Reply-To: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
Message-ID: <XZD_9PsAEASD0FzCJCdWpjaZmlk_2p6NTwJXYo4YjYk=.8808126d-a583-490b-abd7-55da687e344c@github.com>

> Hi all,
> 
> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
> 
> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:

  Missed obsolete test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2012/files
  - new: https://git.openjdk.org/valhalla/pull/2012/files/5e3f8d13..34e7ea45

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

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

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

From darcy at openjdk.org  Mon Feb  2 17:32:29 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Feb 2026 17:32:29 GMT
Subject: RFR: [type-classes] JDK-8376823: Add prototype polynomial class
 [v5]
In-Reply-To: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
Message-ID: <yq1ohMFiug_Uf7hPYmDTV1M8xjaA797RcLUBBp2seoQ=.138549e9-5442-499e-b57b-ddb672760c8f@github.com>

> Add a simple polynomial class over doubles as an example of a ring.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback, etc.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2004/files
  - new: https://git.openjdk.org/valhalla/pull/2004/files/e4172202..ac9a1a09

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

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

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

From vromero at openjdk.org  Mon Feb  2 17:41:58 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 17:41:58 GMT
Subject: RFR: Merge lworld
Message-ID: <u37aU69tD8MTL4vLsrd6zXnGe3mODhKwepMn15bS9jA=.32ff2199-676d-44d2-bbff-85cc0d898b5f@github.com>

Merge branch 'lworld' into bworld_merge_lworld
# Conflicts:
#	test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java
#	test/hotspot/jtreg/runtime/valhalla/inlinetypes/FlattenableSemanticTest.java
#	test/jdk/valhalla/valuetypes/MethodHandleTest.java
#	test/jdk/valhalla/valuetypes/NullRestrictedTest.java
#	test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java

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

Commit messages:
 - Merge branch 'lworld' into bworld_merge_lworld
 - 8376135: [lworld] Add JIT support for NULLABLE_NON_ATOMIC_FLAT layout
 - 8376890: [lworld] Compiler replay crashes when class cannot be loaded after JDK-8375548
 - 8372745: [lworld] Fatal error in native method when running java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java with --enable-preview
 - 8376815: [lworld] compiler/valhalla/inlinetypes/TestTrivialMethods.java still fails after JDK-8373692
 - 8376752: [lworld] clarify/organize Valhalla ProblemLists
 - 8376528: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files
 - 8376046: [lworld] Adjust @NullRestricted tests to remove @Strict
 - 8376825: [lworld] Remove duplicate asmtools from test/lib
 - 8376827: [lworld] fix typo in ProblemListing for JDK-8376815
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/187ac64b...99688b82

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

Changes: https://git.openjdk.org/valhalla/pull/2015/files
  Stats: 27673 lines in 255 files changed: 701 ins; 26720 del; 252 mod
  Patch: https://git.openjdk.org/valhalla/pull/2015.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2015/head:pull/2015

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

From vromero at openjdk.org  Mon Feb  2 17:51:28 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 17:51:28 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <u37aU69tD8MTL4vLsrd6zXnGe3mODhKwepMn15bS9jA=.32ff2199-676d-44d2-bbff-85cc0d898b5f@github.com>
References: <u37aU69tD8MTL4vLsrd6zXnGe3mODhKwepMn15bS9jA=.32ff2199-676d-44d2-bbff-85cc0d898b5f@github.com>
Message-ID: <Zti9j4cfgMrqZ35kiINPT9wpoxVZPhYSi8BOyAiz71M=.e923ab0a-8378-4c61-b171-5dc2ea7733ca@github.com>

> Merge branch 'lworld' into bworld_merge_lworld
> # Conflicts:
> #	test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java
> #	test/hotspot/jtreg/runtime/valhalla/inlinetypes/FlattenableSemanticTest.java
> #	test/jdk/valhalla/valuetypes/MethodHandleTest.java
> #	test/jdk/valhalla/valuetypes/NullRestrictedTest.java
> #	test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 121 commits:

 - Merge branch 'lworld' into bworld_merge_lworld
   
   # Conflicts:
   #	test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java
   #	test/hotspot/jtreg/runtime/valhalla/inlinetypes/FlattenableSemanticTest.java
   #	test/jdk/valhalla/valuetypes/MethodHandleTest.java
   #	test/jdk/valhalla/valuetypes/NullRestrictedTest.java
   #	test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java
 - javac should not place initializers of null restricted fields before the super invocation
   
   Reviewed-by: liach
 - Merge lworld
 - fixing bug in null checks generation
   
   Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
   Reviewed-by: jlahoda
 - Removing commented tests
 - Merge lworld
 - Classfile signature bang support
   
   Reviewed-by: mcimadamore
 - add different flavors to the useSiteNullChecks compiler option
   
   Reviewed-by: mcimadamore
 - Minor cleanup, preview and since
   
   Reviewed-by: vromero
 - add use site null checks for fields
   
   Reviewed-by: liach, mcimadamore
 - ... and 111 more: https://git.openjdk.org/valhalla/compare/2ad3ce16...99688b82

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

Changes: https://git.openjdk.org/valhalla/pull/2015/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2015&range=01
  Stats: 7788 lines in 115 files changed: 7457 ins; 62 del; 269 mod
  Patch: https://git.openjdk.org/valhalla/pull/2015.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2015/head:pull/2015

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

From vromero at openjdk.org  Mon Feb  2 17:51:31 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 17:51:31 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <u37aU69tD8MTL4vLsrd6zXnGe3mODhKwepMn15bS9jA=.32ff2199-676d-44d2-bbff-85cc0d898b5f@github.com>
References: <u37aU69tD8MTL4vLsrd6zXnGe3mODhKwepMn15bS9jA=.32ff2199-676d-44d2-bbff-85cc0d898b5f@github.com>
Message-ID: <OIfP0B7zwLeW3pMCkDvqsCsrg2FIDSmArOoerO1JiKw=.bfa13a2a-9ede-493b-b465-744b8f6de4eb@github.com>

On Mon, 2 Feb 2026 17:33:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into bworld_merge_lworld
> # Conflicts:
> #	test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java
> #	test/hotspot/jtreg/runtime/valhalla/inlinetypes/FlattenableSemanticTest.java
> #	test/jdk/valhalla/valuetypes/MethodHandleTest.java
> #	test/jdk/valhalla/valuetypes/NullRestrictedTest.java
> #	test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java

This pull request has now been integrated.

Changeset: 77214d71
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/77214d71864591f3876c3aa4b4ec263813a856b0
Stats:     27673 lines in 255 files changed: 701 ins; 26720 del; 252 mod

Merge lworld

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

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

From qamai at openjdk.org  Mon Feb  2 17:59:08 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Feb 2026 17:59:08 GMT
Subject: [lworld] RFR: 8376702: [lworld] MemNode::optimize_simple_memory_chain
 asserts with "invalid node class: Con"
Message-ID: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>

Hi,

I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.

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

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

Commit messages:
 - Catch the cases when the pointer dies

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

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

From vromero at openjdk.org  Mon Feb  2 18:00:35 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 18:00:35 GMT
Subject: RFR: add javac and javap support for the ACC_NULL_CHECKED flag
Message-ID: <mjknPVeUK5YANpeJL2S001Gw8g-ihhJejZBe_n7Ials=.51644ffd-7334-492f-8a38-1da47fa1c242@github.com>

adding support for the ACC_NULL_CHECKED flag

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

Commit messages:
 - Merge branch 'bworld' into add.support.for.ACC_NULL_CHECKED.flag
 - add javac and javap support for the ACC_NULL_CHECKED flag

Changes: https://git.openjdk.org/valhalla/pull/2017/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2017&range=00
  Stats: 57 lines in 6 files changed: 52 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/2017.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2017/head:pull/2017

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

From rriggs at openjdk.org  Mon Feb  2 18:41:04 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 2 Feb 2026 18:41:04 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v2]
In-Reply-To: <XZD_9PsAEASD0FzCJCdWpjaZmlk_2p6NTwJXYo4YjYk=.8808126d-a583-490b-abd7-55da687e344c@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <XZD_9PsAEASD0FzCJCdWpjaZmlk_2p6NTwJXYo4YjYk=.8808126d-a583-490b-abd7-55da687e344c@github.com>
Message-ID: <7l7hTZg6rrGWe4LOXOlJ2c-6GuBTHvpv8qbVGuwhXTg=.2a3cf79d-3337-404b-b4aa-3a444337fd43@github.com>

On Mon, 2 Feb 2026 17:24:48 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
>> 
>> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed obsolete test

The java file changes look fine.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2012#pullrequestreview-3741245376

From vromero at openjdk.org  Mon Feb  2 18:52:31 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 18:52:31 GMT
Subject: RFR: add javac and javap support for the ACC_NULL_CHECKED flag
 [v2]
In-Reply-To: <mjknPVeUK5YANpeJL2S001Gw8g-ihhJejZBe_n7Ials=.51644ffd-7334-492f-8a38-1da47fa1c242@github.com>
References: <mjknPVeUK5YANpeJL2S001Gw8g-ihhJejZBe_n7Ials=.51644ffd-7334-492f-8a38-1da47fa1c242@github.com>
Message-ID: <X87Vi6MdTMfxP9OUmHTxh8rqFLDs_vOubHk81YnQvnU=.a9925c00-b6f5-4a92-8b44-e4d4c7f2737b@github.com>

> adding support for the ACC_NULL_CHECKED flag

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - tests
 - minor fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2017/files
  - new: https://git.openjdk.org/valhalla/pull/2017/files/56a385ac..77364f33

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

  Stats: 29 lines in 3 files changed: 5 ins; 21 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/2017.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2017/head:pull/2017

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

From vromero at openjdk.org  Mon Feb  2 19:41:32 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 19:41:32 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v5]
In-Reply-To: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
Message-ID: <17Q8uy71TfLGXkbxDMWs2oiuhqqS0Mv9hgpBVGCzIoI=.2bb9c4f4-e0b1-41d6-8db3-7eae7f90a4d0@github.com>

> adding some additional regression tests for local proxy variables
> 
> TIA

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

 - Merge branch 'lworld' into JDK-8376843
 - fixing test annotations
 - making the compiler reusable
 - doc
 - 8376843: [lworld] add more regression tests for local variable proxies

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2008/files
  - new: https://git.openjdk.org/valhalla/pull/2008/files/12401ea5..cfc9a537

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

  Stats: 270 lines in 24 files changed: 150 ins; 35 del; 85 mod
  Patch: https://git.openjdk.org/valhalla/pull/2008.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2008/head:pull/2008

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

From liach at openjdk.org  Mon Feb  2 20:01:12 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 20:01:12 GMT
Subject: RFR: add javac and javap support for the ACC_NULL_CHECKED flag
 [v2]
In-Reply-To: <X87Vi6MdTMfxP9OUmHTxh8rqFLDs_vOubHk81YnQvnU=.a9925c00-b6f5-4a92-8b44-e4d4c7f2737b@github.com>
References: <mjknPVeUK5YANpeJL2S001Gw8g-ihhJejZBe_n7Ials=.51644ffd-7334-492f-8a38-1da47fa1c242@github.com>
 <X87Vi6MdTMfxP9OUmHTxh8rqFLDs_vOubHk81YnQvnU=.a9925c00-b6f5-4a92-8b44-e4d4c7f2737b@github.com>
Message-ID: <GAtUCHH5FtGidlqf6lTNaoqnH9G7UE3dJoPQPWhQh1s=.daccedc1-2a37-4591-91a0-26bb7eac1296@github.com>

On Mon, 2 Feb 2026 18:52:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> adding support for the ACC_NULL_CHECKED flag
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - tests
>  - minor fix

Looks great to me.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2017#pullrequestreview-3741506852

From vromero at openjdk.org  Mon Feb  2 20:38:31 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 20:38:31 GMT
Subject: RFR: add javac and javap support for the ACC_NULL_CHECKED flag
 [v2]
In-Reply-To: <GAtUCHH5FtGidlqf6lTNaoqnH9G7UE3dJoPQPWhQh1s=.daccedc1-2a37-4591-91a0-26bb7eac1296@github.com>
References: <mjknPVeUK5YANpeJL2S001Gw8g-ihhJejZBe_n7Ials=.51644ffd-7334-492f-8a38-1da47fa1c242@github.com>
 <X87Vi6MdTMfxP9OUmHTxh8rqFLDs_vOubHk81YnQvnU=.a9925c00-b6f5-4a92-8b44-e4d4c7f2737b@github.com>
 <GAtUCHH5FtGidlqf6lTNaoqnH9G7UE3dJoPQPWhQh1s=.daccedc1-2a37-4591-91a0-26bb7eac1296@github.com>
Message-ID: <VXrnHMhteDxaPpBHuLcV8c6bQZzVGacWnNfrvOmPF2c=.a520c61f-39ec-4732-94c1-3ee203574f50@github.com>

On Mon, 2 Feb 2026 19:58:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - tests
>>  - minor fix
>
> Looks great to me.

@liach thanks for the review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2017#issuecomment-3837362721

From darcy at openjdk.org  Mon Feb  2 20:40:20 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Feb 2026 20:40:20 GMT
Subject: RFR: [type-classes] JDK-8376823: Add prototype polynomial class
 [v6]
In-Reply-To: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
Message-ID: <iJAKnYC6TxRSd1HgibDQSgrNeb_48syFTtfEH5q5jx4=.136288e5-2f8b-46de-8fb4-5cf736fb1608@github.com>

> Add a simple polynomial class over doubles as an example of a ring.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments and refactor.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2004/files
  - new: https://git.openjdk.org/valhalla/pull/2004/files/ac9a1a09..953de6af

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

  Stats: 76 lines in 1 file changed: 44 ins; 4 del; 28 mod
  Patch: https://git.openjdk.org/valhalla/pull/2004.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2004/head:pull/2004

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

From vromero at openjdk.org  Mon Feb  2 20:43:14 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 20:43:14 GMT
Subject: Integrated: add javac and javap support for the ACC_NULL_CHECKED flag
In-Reply-To: <mjknPVeUK5YANpeJL2S001Gw8g-ihhJejZBe_n7Ials=.51644ffd-7334-492f-8a38-1da47fa1c242@github.com>
References: <mjknPVeUK5YANpeJL2S001Gw8g-ihhJejZBe_n7Ials=.51644ffd-7334-492f-8a38-1da47fa1c242@github.com>
Message-ID: <o2fIk3pmt46-sfmwVo96Z2EssPzyDO4eS2DpJjiOwS0=.2e49f5b3-485d-43c8-b956-7ac4ef0eedfe@github.com>

On Mon, 2 Feb 2026 17:52:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding support for the ACC_NULL_CHECKED flag

This pull request has now been integrated.

Changeset: 636ee540
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/636ee540ceedf2714686e461cbbd9d51141526b0
Stats:     44 lines in 6 files changed: 36 ins; 0 del; 8 mod

add javac and javap support for the ACC_NULL_CHECKED flag

Reviewed-by: liach

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

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

From darcy at openjdk.org  Mon Feb  2 20:49:39 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Feb 2026 20:49:39 GMT
Subject: RFR: [type-classes] JDK-8376823: Add prototype polynomial class
 [v3]
In-Reply-To: <83Hwp5zXw1y0ErZZuYS84vK5mA-KdHrrNAV0lQ7R290=.95115677-8251-4407-9312-b992ce507233@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
 <Uf043F95VILFZ456TkwziSYYuok-glMYwvZNMsfhrQs=.fa80302c-506a-495e-a8dd-960b64053a5f@github.com>
 <TaOu3mtcEwVZFsnnvJUKGcBOTgLdLPyKvbFKkI3bstw=.b9841ee1-3ddb-405f-9676-e4792aceb451@github.com>
 <83Hwp5zXw1y0ErZZuYS84vK5mA-KdHrrNAV0lQ7R290=.95115677-8251-4407-9312-b992ce507233@github.com>
Message-ID: <MQZ_dfwhScHWvW9WMi3AnVTkjFCHPr1RMLGv66GrtbE=.e614a6d8-1f99-4504-864a-80020d71d772@github.com>

On Sat, 31 Jan 2026 23:14:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Just curious, are we planning to experience with a more generic polynomial that takes an eligible numerical type, like ones that take float or textbook imaginary?
> 
> Yes, long-term that is a possibility -- that was part of the motivation for naming the class "PolynomialDouble" rather than just "Polynomial." Conceptually, `Polynomial<N extends Numeric>` would make sense, perhaps with some mild side-conditions on Numerics.

A bit more detail, the add/subtract operations on a polynomial use the add/subtract/negate operations on the type of the coefficient.  Polynomial multiply uses add/subtract/negate/multiply on the type of the coefficient.

Therefore, hypothetically `instantiating Polynomial<SomeRing>` would work fine for polynomial add, subtract, and multiply. (An implementation of "`Polynomial<double>`" more sophisticated than this prototype would want to use a more accurate summation technique to compute the coefficients of a polynomial product.)

For polynomial division, looks like the coefficients to be a field (or field like) so that dividing the coefficient values yields a single value that can be used for more computations.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2004#issuecomment-3837391860

From vromero at openjdk.org  Mon Feb  2 20:53:36 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 20:53:36 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v6]
In-Reply-To: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
Message-ID: <Nz5A4Z124Zp-d_KniW9x72NHtbX0UWGh274Iy31rxKM=.6203bc58-475b-4f7c-b93f-c64cbc724908@github.com>

> adding some additional regression tests for local proxy variables
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  fail if there is a compilation error

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2008/files
  - new: https://git.openjdk.org/valhalla/pull/2008/files/cfc9a537..08d984a5

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

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

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

From matsaave at openjdk.org  Mon Feb  2 21:36:40 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 2 Feb 2026 21:36:40 GMT
Subject: [lworld] RFR: 8351362: [lworld] Post-process @StrictInit
 annotation for testing [v4]
In-Reply-To: <-A2P7_cZRyt4LB2kosWgOFUnEmIJhAw5KbnyBGcGvXI=.b0ce58ef-d3e5-4eaa-a5b6-e7aeb5b622e5@github.com>
References: <dGMUSv-hrFxeK3q1FOk36_PNZXs5G6XPADICkj0UM-8=.49b2a1d9-abda-4b18-91df-cf473bb697d8@github.com>
 <-A2P7_cZRyt4LB2kosWgOFUnEmIJhAw5KbnyBGcGvXI=.b0ce58ef-d3e5-4eaa-a5b6-e7aeb5b622e5@github.com>
Message-ID: <qvWa50KPwEhgBNzDAc7WSXLgfPF7DhemdpLymlV9gZg=.1d657792-accc-4901-bce4-10a52a1663c0@github.com>

On Fri, 30 Jan 2026 21:25:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> PR 4 in the series of strict removal. PR 3 is #1959. PR 5 is #1961.
>> 
>> Removes all remaining occurrences of `jdk.internal.vm.annotation.Strict` and `@Strict\b` regex in all `.java` files. They are migrated to the post-processor included in this PR that is similar to test/lib ClassFileInstaller. Note there are still occurrences in jasm/jcod files, but those won't matter.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/plain-strict
>  - Merge branch 'test/remove-strict' into test/plain-strict
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/remove-strict
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/remove-strict
>  - Migrate interal strict to processor anno
>  - Redundancy in dummy source
>  - Merge branch 'test/strict-out' into test/remove-strict
>  - Spurious test removal, should be removed by hotspot change instead
>  - Remove @Strict where @NullRestricted is present
>  - Purge missed jdk internal annotation export
>  - ... and 3 more: https://git.openjdk.org/valhalla/compare/fe2331d9...a515b520

LGTM, thanks! I want to note that StrictStaticFieldsTest.java? and StrictInstanceFields.java remain problem listed and may require further changes once they're enabled

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1960#pullrequestreview-3741769857

From matsaave at openjdk.org  Mon Feb  2 21:39:33 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 2 Feb 2026 21:39:33 GMT
Subject: [lworld] RFR: 8376358: [lworld]
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 fails assert(oopDesc::is_oop(obj)) failed: not an oop
In-Reply-To: <wQyuKgz8R220tEwkd0FUEL06Bie7PXGaGHLgsdGpyyE=.94cd1419-e02c-4976-a9d6-c8f36e818a4d@github.com>
References: <bBV6k2Ds0REmRQKyiCDG7pfdRns9hWneC3E0z6qLjEg=.27cb65eb-c551-47f2-8247-30ba919b0127@github.com>
 <wQyuKgz8R220tEwkd0FUEL06Bie7PXGaGHLgsdGpyyE=.94cd1419-e02c-4976-a9d6-c8f36e818a4d@github.com>
Message-ID: <-LDxH-G9YYpRAWW55YxtPce2Y6HTFkcF3yAdcMaHRNc=.ac042d89-e2aa-4f60-963b-8ee1fd16dd7c@github.com>

On Mon, 2 Feb 2026 09:10:06 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> This test failed intermittently likely due to a gap between the array creation and the oop handle creation. Verified with repeated testing.
>
> Looks good.

Thanks for the reviews @jsikstro and @Arraying!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1986#issuecomment-3837511508

From matsaave at openjdk.org  Mon Feb  2 21:39:34 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 2 Feb 2026 21:39:34 GMT
Subject: [lworld] Integrated: 8376358: [lworld]
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 fails assert(oopDesc::is_oop(obj)) failed: not an oop
In-Reply-To: <bBV6k2Ds0REmRQKyiCDG7pfdRns9hWneC3E0z6qLjEg=.27cb65eb-c551-47f2-8247-30ba919b0127@github.com>
References: <bBV6k2Ds0REmRQKyiCDG7pfdRns9hWneC3E0z6qLjEg=.27cb65eb-c551-47f2-8247-30ba919b0127@github.com>
Message-ID: <WjbqRGXTdLUwGsAVdFLV6XFa26PPJVa8ak49a_3fCTE=.5882c057-3520-43fa-a4e9-a97962215fb7@github.com>

On Tue, 27 Jan 2026 21:57:41 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This test failed intermittently likely due to a gap between the array creation and the oop handle creation. Verified with repeated testing.

This pull request has now been integrated.

Changeset: 12c4fbac
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/12c4fbacb4a0898f8402815b0d0e8141e2d23625
Stats:     3 lines in 1 file changed: 2 ins; 1 del; 0 mod

8376358: [lworld] runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java fails assert(oopDesc::is_oop(obj)) failed: not an oop

Reviewed-by: jsikstro, phubner

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

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

From liach at openjdk.org  Mon Feb  2 21:39:42 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 21:39:42 GMT
Subject: RFR: [type-classes] JDK-8376823: Add prototype polynomial class
 [v6]
In-Reply-To: <iJAKnYC6TxRSd1HgibDQSgrNeb_48syFTtfEH5q5jx4=.136288e5-2f8b-46de-8fb4-5cf736fb1608@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
 <iJAKnYC6TxRSd1HgibDQSgrNeb_48syFTtfEH5q5jx4=.136288e5-2f8b-46de-8fb4-5cf736fb1608@github.com>
Message-ID: <OwjdDxExJDV9mSTAp0y_mpei0mwEnHJ2ShmFnMLX0EU=.b9168627-6581-4b4b-b33b-4da8f85a3c9e@github.com>

On Mon, 2 Feb 2026 20:40:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a simple polynomial class over doubles as an example of a ring.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments and refactor.

Good that we are encapsulating degree with methods; might add a comment to indicate this intention, like no direct access for lazy fields.

Also, I noted we use (`this.`)`coeffs.length` a lot. How is it distinct from `deg()`? Hope we can clarify on that as well.

Otherwise, looks nice in concept.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2004#issuecomment-3837511052

From liach at openjdk.org  Mon Feb  2 21:41:36 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 21:41:36 GMT
Subject: [lworld] RFR: 8351362: [lworld] Post-process @StrictInit
 annotation for testing [v4]
In-Reply-To: <-A2P7_cZRyt4LB2kosWgOFUnEmIJhAw5KbnyBGcGvXI=.b0ce58ef-d3e5-4eaa-a5b6-e7aeb5b622e5@github.com>
References: <dGMUSv-hrFxeK3q1FOk36_PNZXs5G6XPADICkj0UM-8=.49b2a1d9-abda-4b18-91df-cf473bb697d8@github.com>
 <-A2P7_cZRyt4LB2kosWgOFUnEmIJhAw5KbnyBGcGvXI=.b0ce58ef-d3e5-4eaa-a5b6-e7aeb5b622e5@github.com>
Message-ID: <qA5Y8HQQrGYZWOPjWc-hiv7hMPA6_J7WPH4BtSrfigc=.80cfd120-5cc2-41d5-a2f9-9dbe13a83a0f@github.com>

On Fri, 30 Jan 2026 21:25:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> PR 4 in the series of strict removal. PR 3 is #1959. PR 5 is #1961.
>> 
>> Removes all remaining occurrences of `jdk.internal.vm.annotation.Strict` and `@Strict\b` regex in all `.java` files. They are migrated to the post-processor included in this PR that is similar to test/lib ClassFileInstaller. Note there are still occurrences in jasm/jcod files, but those won't matter.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/plain-strict
>  - Merge branch 'test/remove-strict' into test/plain-strict
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/remove-strict
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/remove-strict
>  - Migrate interal strict to processor anno
>  - Redundancy in dummy source
>  - Merge branch 'test/strict-out' into test/remove-strict
>  - Spurious test removal, should be removed by hotspot change instead
>  - Remove @Strict where @NullRestricted is present
>  - Purge missed jdk internal annotation export
>  - ... and 3 more: https://git.openjdk.org/valhalla/compare/fe2331d9...a515b520

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1960#issuecomment-3837516921

From liach at openjdk.org  Mon Feb  2 21:41:39 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 21:41:39 GMT
Subject: [lworld] Integrated: 8351362: [lworld] Post-process @StrictInit
 annotation for testing
In-Reply-To: <dGMUSv-hrFxeK3q1FOk36_PNZXs5G6XPADICkj0UM-8=.49b2a1d9-abda-4b18-91df-cf473bb697d8@github.com>
References: <dGMUSv-hrFxeK3q1FOk36_PNZXs5G6XPADICkj0UM-8=.49b2a1d9-abda-4b18-91df-cf473bb697d8@github.com>
Message-ID: <fEO2eFSaCLk7MrvsBSeBoGPLRS6ATmd2-zMKgbQLO60=.54f83d29-af98-4400-b2dd-9fa2ed492211@github.com>

On Sun, 25 Jan 2026 06:53:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> PR 4 in the series of strict removal. PR 3 is #1959. PR 5 is #1961.
> 
> Removes all remaining occurrences of `jdk.internal.vm.annotation.Strict` and `@Strict\b` regex in all `.java` files. They are migrated to the post-processor included in this PR that is similar to test/lib ClassFileInstaller. Note there are still occurrences in jasm/jcod files, but those won't matter.

This pull request has now been integrated.

Changeset: 68fc069b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/68fc069babeff44ebdfeea75bbd493dba120da50
Stats:     611 lines in 13 files changed: 544 ins; 7 del; 60 mod

8351362: [lworld] Post-process @StrictInit annotation for testing

Reviewed-by: matsaave

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

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

From liach at openjdk.org  Mon Feb  2 21:50:11 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 21:50:11 GMT
Subject: [lworld] RFR: 8376047: [lworld] Remove javac special treatment of
 @Strict [v3]
In-Reply-To: <8-UVZreBmhL9HoZeuNIxiZ32MNHe7eymHvO-Gmo1E2s=.50c96d16-1f8a-4f05-8143-625d26959d65@github.com>
References: <8-UVZreBmhL9HoZeuNIxiZ32MNHe7eymHvO-Gmo1E2s=.50c96d16-1f8a-4f05-8143-625d26959d65@github.com>
Message-ID: <qnwvqAnwB9fS0j85-lIAeyFE0OBCMLmHkSnKehP73c8=.5b4f908e-20ed-447c-87de-233029cd9998@github.com>

> PR 5, the final, in the series of strict removal. PR 4 is #1960.
> 
> Remove the `jdk.internal.vm.annotation.Strict` annotation, and some javac flags now obsolete due to the removal.

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

 - Redundant change
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/remove-strict-javac
 - Merge branch 'test/plain-strict' into fix/remove-strict-javac
 - Merge branch 'test/remove-strict' into test/plain-strict
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/remove-strict
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/remove-strict
 - Remove strict
 - Migrate interal strict to processor anno
 - Redundancy in dummy source
 - Merge branch 'test/strict-out' into test/remove-strict
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/68fc069b...f80bcc16

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

Changes: https://git.openjdk.org/valhalla/pull/1961/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1961&range=02
  Stats: 77 lines in 10 files changed: 0 ins; 64 del; 13 mod
  Patch: https://git.openjdk.org/valhalla/pull/1961.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1961/head:pull/1961

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

From darcy at openjdk.org  Mon Feb  2 22:03:33 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Feb 2026 22:03:33 GMT
Subject: RFR: [type-classes] JDK-8376823: Add prototype polynomial class
 [v6]
In-Reply-To: <OwjdDxExJDV9mSTAp0y_mpei0mwEnHJ2ShmFnMLX0EU=.b9168627-6581-4b4b-b33b-4da8f85a3c9e@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
 <iJAKnYC6TxRSd1HgibDQSgrNeb_48syFTtfEH5q5jx4=.136288e5-2f8b-46de-8fb4-5cf736fb1608@github.com>
 <OwjdDxExJDV9mSTAp0y_mpei0mwEnHJ2ShmFnMLX0EU=.b9168627-6581-4b4b-b33b-4da8f85a3c9e@github.com>
Message-ID: <s6Wtsc0ZIrkFH5YIcJMrzPH4hsha-sZtdqWGjCj6CF4=.89a8b88f-8448-4e25-b916-68b2a834f9af@github.com>

On Mon, 2 Feb 2026 21:35:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> Good that we are encapsulating degree with methods; might add a comment to indicate this intention, like no direct access for lazy fields.
> 
> Also, I noted we use (`this.`)`coeffs.length` a lot. How is it distinct from `deg()`? Hope we can clarify on that as well.
> 
> Otherwise, looks nice in concept.

The notion of "degree" is a polynomial concept while the length of the backing array is an implementation artifact. With this data structure; degree is _almost_ length - 1. The exception is a zero polynomial, which needs special handling somehow since its degree is defined to not be 0 -- as would be the case for any other constant polynomial -- but -1 (or sometimes -infinity).

Writing this comment, this might tip my scales to internally use an empty array to special case zero. That way, the degree would be one less than the length is all cases.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2004#issuecomment-3837572397

From liach at openjdk.org  Mon Feb  2 22:11:03 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 22:11:03 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v6]
In-Reply-To: <Nz5A4Z124Zp-d_KniW9x72NHtbX0UWGh274Iy31rxKM=.6203bc58-475b-4f7c-b93f-c64cbc724908@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
 <Nz5A4Z124Zp-d_KniW9x72NHtbX0UWGh274Iy31rxKM=.6203bc58-475b-4f7c-b93f-c64cbc724908@github.com>
Message-ID: <C3_ujWg_Ko4K1VMOlE4POmt8nIJeMKBkJMyDyjK8xdU=.ca9195d7-d03d-477a-ad50-7f9255d1e9dd@github.com>

On Mon, 2 Feb 2026 20:53:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> adding some additional regression tests for local proxy variables
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fail if there is a compilation error

Looks good, sorry for a slow review

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2008#pullrequestreview-3741855215

From vromero at openjdk.org  Mon Feb  2 22:21:57 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 22:21:57 GMT
Subject: [lworld] RFR: 8376843: [lworld] add more regression tests for
 local variable proxies [v6]
In-Reply-To: <C3_ujWg_Ko4K1VMOlE4POmt8nIJeMKBkJMyDyjK8xdU=.ca9195d7-d03d-477a-ad50-7f9255d1e9dd@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
 <Nz5A4Z124Zp-d_KniW9x72NHtbX0UWGh274Iy31rxKM=.6203bc58-475b-4f7c-b93f-c64cbc724908@github.com>
 <C3_ujWg_Ko4K1VMOlE4POmt8nIJeMKBkJMyDyjK8xdU=.ca9195d7-d03d-477a-ad50-7f9255d1e9dd@github.com>
Message-ID: <ZesrJoj6YoSr3pgIdsSBOIwbvfBVFAIfFj_QrQoF8BQ=.37334b3f-2c5d-445f-90d3-acbc785c833e@github.com>

On Mon, 2 Feb 2026 22:08:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail if there is a compilation error
>
> Looks good, sorry for a slow review

@liach thanks again for the reviews

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

PR Comment: https://git.openjdk.org/valhalla/pull/2008#issuecomment-3837612481

From vromero at openjdk.org  Mon Feb  2 22:21:58 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Feb 2026 22:21:58 GMT
Subject: [lworld] Integrated: 8376843: [lworld] add more regression tests for
 local variable proxies
In-Reply-To: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
References: <pkUEb-S6ECL2JNaxB4xVzXf0CRN_k2rb26Arb6daxow=.a2c864fc-5e51-4d6d-a5a8-5eac1d202bff@github.com>
Message-ID: <J0BylWfum0NlJfLsL9_mi2Bdu0UB3UxYwkdkCGusKm4=.44c1232f-36c1-4b84-a5b6-5703bfb1f202@github.com>

On Sun, 1 Feb 2026 01:06:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding some additional regression tests for local proxy variables
> 
> TIA

This pull request has now been integrated.

Changeset: a62dd02b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a62dd02b551e51c9d060ccf2b5d4a595512f150d
Stats:     276 lines in 5 files changed: 250 ins; 12 del; 14 mod

8376843: [lworld] add more regression tests for local variable proxies

Reviewed-by: liach

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

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

From darcy at openjdk.org  Mon Feb  2 22:43:42 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Feb 2026 22:43:42 GMT
Subject: RFR: [type-classes] JDK-8376823: Add prototype polynomial class
 [v7]
In-Reply-To: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
Message-ID: <tl4IfBAR7dEGj5zyIsRGazOViMqbPLgxDPA8eCsBoj4=.3e31c51d-6e43-4124-b8d5-3bd9d68eee18@github.com>

> Add a simple polynomial class over doubles as an example of a ring.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Refactor based on PR discussions.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2004/files
  - new: https://git.openjdk.org/valhalla/pull/2004/files/953de6af..348390b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=2004&range=06
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=2004&range=05-06

  Stats: 52 lines in 1 file changed: 17 ins; 8 del; 27 mod
  Patch: https://git.openjdk.org/valhalla/pull/2004.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2004/head:pull/2004

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

From darcy at openjdk.org  Mon Feb  2 22:43:43 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Feb 2026 22:43:43 GMT
Subject: RFR: [type-classes] JDK-8376823: Add prototype polynomial class
 [v6]
In-Reply-To: <s6Wtsc0ZIrkFH5YIcJMrzPH4hsha-sZtdqWGjCj6CF4=.89a8b88f-8448-4e25-b916-68b2a834f9af@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
 <iJAKnYC6TxRSd1HgibDQSgrNeb_48syFTtfEH5q5jx4=.136288e5-2f8b-46de-8fb4-5cf736fb1608@github.com>
 <OwjdDxExJDV9mSTAp0y_mpei0mwEnHJ2ShmFnMLX0EU=.b9168627-6581-4b4b-b33b-4da8f85a3c9e@github.com>
 <s6Wtsc0ZIrkFH5YIcJMrzPH4hsha-sZtdqWGjCj6CF4=.89a8b88f-8448-4e25-b916-68b2a834f9af@github.com>
Message-ID: <HkVZOU1SEC-fi5e8JYzAnJkhNfXUmjkFsfGxUR3o9wY=.7b8f50a8-2b31-403c-b0b6-f7ab1287e7c0@github.com>

On Mon, 2 Feb 2026 22:00:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Good that we are encapsulating degree with methods; might add a comment to indicate this intention, like no direct access for lazy fields.
> > Also, I noted we use (`this.`)`coeffs.length` a lot. How is it distinct from `deg()`? Hope we can clarify on that as well.
> > Otherwise, looks nice in concept.
> 
> The notion of "degree" is a polynomial concept while the length of the backing array is an implementation artifact. With this data structure; degree is _almost_ length - 1. The exception is a zero polynomial, which needs special handling somehow since its degree is defined to not be 0 -- as would be the case for any other constant polynomial -- but -1 (or sometimes -infinity).
> 
> Writing this comment, this might tip my scales to internally use an empty array to special case zero. That way, the degree would be one less than the length is all cases.

Refactoring pushed; I'll go over this again on my own, but will likely push a variation of this later today. Thanks for the helpful discussions.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2004#issuecomment-3837661374

From liach at openjdk.org  Mon Feb  2 22:59:18 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 22:59:18 GMT
Subject: [lworld] RFR: 8376047: [lworld] Remove javac special treatment of
 @Strict [v3]
In-Reply-To: <qnwvqAnwB9fS0j85-lIAeyFE0OBCMLmHkSnKehP73c8=.5b4f908e-20ed-447c-87de-233029cd9998@github.com>
References: <8-UVZreBmhL9HoZeuNIxiZ32MNHe7eymHvO-Gmo1E2s=.50c96d16-1f8a-4f05-8143-625d26959d65@github.com>
 <qnwvqAnwB9fS0j85-lIAeyFE0OBCMLmHkSnKehP73c8=.5b4f908e-20ed-447c-87de-233029cd9998@github.com>
Message-ID: <V4D6YQol1imenrHM1Lts1--WKubkzw1UxKB7c9NJkZk=.f734772f-4a83-4450-8973-b0715977c073@github.com>

On Mon, 2 Feb 2026 21:50:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> PR 5, the final, in the series of strict removal. PR 4 is #1960.
>> 
>> Remove the `jdk.internal.vm.annotation.Strict` annotation, and some javac flags now obsolete due to the removal.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Redundant change
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/remove-strict-javac
>  - Merge branch 'test/plain-strict' into fix/remove-strict-javac
>  - Merge branch 'test/remove-strict' into test/plain-strict
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/remove-strict
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/remove-strict
>  - Remove strict
>  - Migrate interal strict to processor anno
>  - Redundancy in dummy source
>  - Merge branch 'test/strict-out' into test/remove-strict
>  - ... and 6 more: https://git.openjdk.org/valhalla/compare/68fc069b...f80bcc16

A final CI run confirmed there is no problem with tier 1 and 2. This should cover all test Java files. Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1961#issuecomment-3837699446

From liach at openjdk.org  Mon Feb  2 22:59:19 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 22:59:19 GMT
Subject: [lworld] Integrated: 8376047: [lworld] Remove javac special treatment
 of @Strict
In-Reply-To: <8-UVZreBmhL9HoZeuNIxiZ32MNHe7eymHvO-Gmo1E2s=.50c96d16-1f8a-4f05-8143-625d26959d65@github.com>
References: <8-UVZreBmhL9HoZeuNIxiZ32MNHe7eymHvO-Gmo1E2s=.50c96d16-1f8a-4f05-8143-625d26959d65@github.com>
Message-ID: <XwF2Iq-09E3H4pXPojDvJHPxG1QmeK7e1_f66B_BpTs=.8c3a2b04-7b17-4e4a-9dae-8fe1cd52f67f@github.com>

On Sun, 25 Jan 2026 07:28:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> PR 5, the final, in the series of strict removal. PR 4 is #1960.
> 
> Remove the `jdk.internal.vm.annotation.Strict` annotation, and some javac flags now obsolete due to the removal.

This pull request has now been integrated.

Changeset: 7c8fb91b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7c8fb91ba4ef22d84cb31b9dddedfad742d5a8e7
Stats:     77 lines in 10 files changed: 0 ins; 64 del; 13 mod

8376047: [lworld] Remove javac special treatment of @Strict

Reviewed-by: vromero

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

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

From phubner at openjdk.org  Mon Feb  2 23:03:40 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 2 Feb 2026 23:03:40 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
Message-ID: <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>

> Hi all,
> 
> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
> 
> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

Paul H?bner 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 13 additional commits since the last revision:

 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
 - Missed obsolete test
 - Years
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
 - substitutability contract changed
 - Legacy handling in ProcessHandleImpl
 - typo
 - Test flags
 - Dead stuff
 - Merge branch 'JDK-8372954' of github.com:Arraying/valhalla into JDK-8372954
 - ... and 3 more: https://git.openjdk.org/valhalla/compare/708770ec...29344379

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2012/files
  - new: https://git.openjdk.org/valhalla/pull/2012/files/34e7ea45..29344379

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

  Stats: 963 lines in 27 files changed: 792 ins; 80 del; 91 mod
  Patch: https://git.openjdk.org/valhalla/pull/2012.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2012/head:pull/2012

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

From vromero at openjdk.org  Tue Feb  3 01:50:02 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 01:50:02 GMT
Subject: RFR: Remove redundant null checks [v9]
In-Reply-To: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
References: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
Message-ID: <QT5iW81zv5MNBRb0lmm7G8sRKecOBfSTjCjpvfQu1Bs=.23813429-65f5-4d89-a65a-ea27d247734e@github.com>

> some of the null checks javac generates are redundant and can be removed

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - fixes needed after merge
 - merge with bworld
 - Merge branch 'bworld' into remove.redundant.null.checks
 - minor change
 - addressing review comments
 - adding test cases
 - adding more tests
 - adding more tests
 - minor change
 - another change
 - ... and 4 more: https://git.openjdk.org/valhalla/compare/636ee540...c0d70e69

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

Changes: https://git.openjdk.org/valhalla/pull/1947/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=08
  Stats: 332 lines in 4 files changed: 274 ins; 11 del; 47 mod
  Patch: https://git.openjdk.org/valhalla/pull/1947.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1947/head:pull/1947

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

From fyang at openjdk.org  Tue Feb  3 02:05:36 2026
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Feb 2026 02:05:36 GMT
Subject: [lworld] RFR: 8376883: [lworld] Only enable
 compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86
In-Reply-To: <K1JUIlsv91c4al9AFkVW06jCH1nV97O9IMB0sLbmEAM=.c2c248db-9a38-4d68-9231-c48b3db895b0@github.com>
References: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
 <K1JUIlsv91c4al9AFkVW06jCH1nV97O9IMB0sLbmEAM=.c2c248db-9a38-4d68-9231-c48b3db895b0@github.com>
Message-ID: <S7J7MMSkwAVO_pOzZ2cFemu8OacgosZzvi3Jk4DGbLo=.9c0fc4cf-4e72-4097-af41-260e756d4161@github.com>

On Mon, 2 Feb 2026 09:32:28 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi,
>> 
>> Please consider this small test-only change.
>> Seems this test depends on the two optimizations: -XX:+InlineTypePassFieldsAsArgs and -XX:-InlineTypeReturnedAsFields.
>> It fails without either of them. So it might be more reasonable to only enable it for platforms which implement these
>> two optimizations.
>> 
>> Verified on linux-aarch64 platform.
>
> Thanks for the patch! Looks good to me, but I think it'd be good to get a compiler expert to take a look as well.

@Arraying @TobiHartmann : Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2009#issuecomment-3838426344

From duke at openjdk.org  Tue Feb  3 02:05:37 2026
From: duke at openjdk.org (duke)
Date: Tue, 3 Feb 2026 02:05:37 GMT
Subject: [lworld] RFR: 8376883: [lworld] Only enable
 compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86
In-Reply-To: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
References: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
Message-ID: <1Xl56ljQ8OyIk3h5MlBjSPO-2cxEpRvkX3crR1Nc1yk=.386b7efc-254e-47de-96b6-20c3894669d8@github.com>

On Mon, 2 Feb 2026 09:09:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi,
> 
> Please consider this small test-only change.
> Seems this test depends on the two optimizations: -XX:+InlineTypePassFieldsAsArgs and -XX:-InlineTypeReturnedAsFields.
> It fails without either of them. So it might be more reasonable to only enable it for platforms which implement these
> two optimizations.
> 
> Verified on linux-aarch64 platform.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/2009#issuecomment-3838429244

From darcy at openjdk.org  Tue Feb  3 02:11:32 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Feb 2026 02:11:32 GMT
Subject: RFR: [type-classes] JDK-8376823: Add prototype polynomial class
 [v8]
In-Reply-To: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
Message-ID: <1tcqiGpNRFg23pvUs828jnB0YD6X9hsMhKbrlqB8Lzs=.4a25d55b-7881-41cf-837c-7f58d0f5a334@github.com>

> Add a simple polynomial class over doubles as an example of a ring.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Refinements

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2004/files
  - new: https://git.openjdk.org/valhalla/pull/2004/files/348390b8..95a97723

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=2004&range=07
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=2004&range=06-07

  Stats: 39 lines in 1 file changed: 11 ins; 4 del; 24 mod
  Patch: https://git.openjdk.org/valhalla/pull/2004.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2004/head:pull/2004

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

From vromero at openjdk.org  Tue Feb  3 02:40:09 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 02:40:09 GMT
Subject: RFR: Remove redundant null checks [v10]
In-Reply-To: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
References: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
Message-ID: <Qtu0jHBKSRO1ksdPMTqu0-ScPk570iEgG13XPNU2zi8=.58596b78-549d-4a6e-9126-cf6f39d6a20e@github.com>

> some of the null checks javac generates are redundant and can be removed

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1947/files
  - new: https://git.openjdk.org/valhalla/pull/1947/files/c0d70e69..69e7b3ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=09
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=08-09

  Stats: 13 lines in 2 files changed: 7 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1947.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1947/head:pull/1947

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

From darcy at openjdk.org  Tue Feb  3 02:48:33 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Feb 2026 02:48:33 GMT
Subject: Integrated: [type-classes] JDK-8376823: Add prototype polynomial class
In-Reply-To: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
References: <u9aDfMXKQyjnNXGOmwLJb0EZ26p2vfFLAUWB4xyksoY=.047759d6-fdf4-41c2-8e29-1986e97dc6d6@github.com>
Message-ID: <u3XRnNvfSFqnwLMh3R7160dUsJqPL2iBch9Qex6MUZQ=.46b74170-a776-4beb-82c8-4a026c505e6a@github.com>

On Fri, 30 Jan 2026 18:11:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add a simple polynomial class over doubles as an example of a ring.

This pull request has now been integrated.

Changeset: 66f499cb
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/66f499cb37c97bca6a77367e25789b39cb27e10e
Stats:     613 lines in 1 file changed: 613 ins; 0 del; 0 mod

[type-classes] JDK-8376823: Add prototype polynomial class

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

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

From vromero at openjdk.org  Tue Feb  3 02:59:28 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 02:59:28 GMT
Subject: RFR: Remove redundant null checks [v10]
In-Reply-To: <Qtu0jHBKSRO1ksdPMTqu0-ScPk570iEgG13XPNU2zi8=.58596b78-549d-4a6e-9126-cf6f39d6a20e@github.com>
References: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
 <Qtu0jHBKSRO1ksdPMTqu0-ScPk570iEgG13XPNU2zi8=.58596b78-549d-4a6e-9126-cf6f39d6a20e@github.com>
Message-ID: <UiyrHRm296qtfYEWMPd4ei2X0qOHzRu0_cpdPWmiKEs=.7a73352c-9678-46f5-a004-e2fc595cb7de@github.com>

On Tue, 3 Feb 2026 02:40:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> some of the null checks javac generates are redundant and can be removed
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

test/langtools/tools/javac/nullability/RuntimeNullChecks.java line 820:

> 818:     @Test
> 819:     public void testUseSideChecksForFieldsSepCompilation(Path base) throws Exception {
> 820:         testUseSiteForFieldsSeparateCompilationHelper(base,

I think I will fold this test with the one above

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1947#discussion_r2756951646

From liach at openjdk.org  Tue Feb  3 04:28:34 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Feb 2026 04:28:34 GMT
Subject: [lworld] RFR: 8376883: [lworld] Only enable
 compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86
In-Reply-To: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
References: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
Message-ID: <ewEdNq2PFaBrR7xXxSW_1hJz4-ql8ilLPc4XVVmvlXQ=.a2ce1ff1-a948-42dc-9271-a5a8cd2d6a83@github.com>

On Mon, 2 Feb 2026 09:09:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi,
> 
> Please consider this small test-only change.
> Seems this test depends on the two optimizations: -XX:+InlineTypePassFieldsAsArgs and -XX:-InlineTypeReturnedAsFields.
> It fails without either of them. So it might be more reasonable to only enable it for platforms which implement these
> two optimizations.
> 
> Verified on linux-aarch64 platform.

Thanks for this fix!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2009#issuecomment-3838974870

From fyang at openjdk.org  Tue Feb  3 04:28:35 2026
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Feb 2026 04:28:35 GMT
Subject: [lworld] Integrated: 8376883: [lworld] Only enable
 compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86
In-Reply-To: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
References: <k_lFEg-FKZIjcmX9rajF6FSdIvKqajzCzWzP02wb4iw=.7d6043e0-7b83-414b-90b5-cea8389cb55f@github.com>
Message-ID: <rE7_XH5xEZhaiDmncVriwOZE3rannZ98yvVXJieOM5I=.927de722-f3d4-4a3d-844d-ce4968dd54d9@github.com>

On Mon, 2 Feb 2026 09:09:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi,
> 
> Please consider this small test-only change.
> Seems this test depends on the two optimizations: -XX:+InlineTypePassFieldsAsArgs and -XX:-InlineTypeReturnedAsFields.
> It fails without either of them. So it might be more reasonable to only enable it for platforms which implement these
> two optimizations.
> 
> Verified on linux-aarch64 platform.

This pull request has now been integrated.

Changeset: 5c2c8f5e
Author:    Fei Yang <fyang at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5c2c8f5ee73a91a5d82553edb9a3093daffad065
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8376883: [lworld] Only enable compiler/valhalla/inlinetypes/TestTrivialMethods.java for aarch64 and x86

Reviewed-by: phubner, thartmann

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

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

From liach at openjdk.org  Tue Feb  3 04:46:04 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Feb 2026 04:46:04 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove Unsafe.make/finishPrivateBuffer
Message-ID: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>

WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...

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

Commit messages:
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
 - Missed test
 - Rollback breaking change
 - Remove private buffer

Changes: https://git.openjdk.org/valhalla/pull/2018/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2018&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373375
  Stats: 462 lines in 14 files changed: 6 ins; 416 del; 40 mod
  Patch: https://git.openjdk.org/valhalla/pull/2018.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2018/head:pull/2018

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

From dsimms at openjdk.org  Tue Feb  3 06:41:56 2026
From: dsimms at openjdk.org (David Simms)
Date: Tue, 3 Feb 2026 06:41:56 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <--AC0E9ruoX3cAVBZq_c6qujs4fX9o4e45mWQhhIy6s=.945a9f92-5ada-40cb-915e-c37fc128c434@github.com>

Merge jdk-27+6

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_27_6
 - Valhalla follow up for 8341630
 - Merge tag 'jdk-27+6' into lworld_merge_jdk_27_6
 - 8375458: Check legal folder of JDK image for unwanted files
 - 8375978: G1: Convert G1Policy to use Atomic<T>
 - 8375977: G1: Convert JVMCICleaningTask to use Atomic<T>
 - 8375618: Incorrect assert in CastLLNode::Ideal
 - 8375616: G1: Convert G1BatchedTask to use Atomic<T>
 - 8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event
 - 8375534: Debug method 'pp' should support compressed oops
 - ... and 86 more: https://git.openjdk.org/valhalla/compare/5c2c8f5e...913405e3

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

Changes: https://git.openjdk.org/valhalla/pull/2019/files
  Stats: 13038 lines in 360 files changed: 8115 ins; 1842 del; 3081 mod
  Patch: https://git.openjdk.org/valhalla/pull/2019.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2019/head:pull/2019

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

From mchevalier at openjdk.org  Tue Feb  3 08:09:31 2026
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 3 Feb 2026 08:09:31 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v2]
In-Reply-To: <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <o04pcdsUHYUmnrBXoGMAw_-7HD4jF0QTKUb3SVVGSjM=.4127cdaf-15e5-48ce-8506-893fa17f22e2@github.com>
 <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>
Message-ID: <JQxs3T4rBFp-eHF06Vb0OCTm8iXK7rnUISLHkZCjHq4=.01a14be6-1973-4b16-95c6-9bb468eb07e5@github.com>

On Mon, 2 Feb 2026 16:36:07 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Details
>>  - exception handling
>>  - oops
>>  - Also cache correctly whole stable fields
>>  - fix comment
>>  - Remove debug
>>  - ShouldNotReachHere
>>  - explicit casts
>>  - Clean up
>>  - expand_constant
>
> src/hotspot/share/ci/ciInstanceKlass.cpp line 440:
> 
>> 438: }
>> 439: 
>> 440: int ciInstanceKlass::field_index_by_offset(int offset) {
> 
> Why is assert needs removing?

That allows to find the declared field containing a sub-field only for inline classes, for identity classes, an assert explodes somewhere deep inside. Indeed, for identity classes, this asserts that the offset is the offset of a declared field, regardless of the identitiness of the containing field.

I've seen the single other usage of this method is on inline classes, so it's not surprising this behavior was unnoticed. Also, the assert is running a code not very different from the implementation of this function. Overall, I wasn't convinced it's bringing a lot: the asserts on the results seems enough.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2757769840

From thartmann at openjdk.org  Tue Feb  3 08:27:45 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 08:27:45 GMT
Subject: [lworld] Integrated: 8375086: [lworld] Implicit exception handling in
 inline-cache check is broken
In-Reply-To: <94iZZH5-Ea9ZHlApHvhBHPlkLZWqvaEBSVrxCTJ06yw=.1d1dbf65-d148-4e5e-ae27-1d0cc4ed5bc7@github.com>
References: <94iZZH5-Ea9ZHlApHvhBHPlkLZWqvaEBSVrxCTJ06yw=.1d1dbf65-d148-4e5e-ae27-1d0cc4ed5bc7@github.com>
Message-ID: <sENOM8nUDXmiFmaiiJDfElVPTPPTX0k84Jd89JWaIWA=.e8a4f2bb-2f8e-4dad-ba0c-ff0e72fb74a8@github.com>

On Mon, 2 Feb 2026 13:58:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We crash with a `SIGSEGV` instead of throwing a `NullPointerException` when passing a `null` receiver through an inline cache'd interface call site because the implicit null check that happens when doing the receiver type check in the unverified entry point of the nmethod is not working properly.
> 
> When `SharedRuntime::continuation_for_implicit_exception` checks where the `IMPLICIT_NULL` exception came from, it does not recognize the entry point:
> https://github.com/openjdk/valhalla/blob/55c80fedfcee5d3b113cdf38d64c1bcac8632c9a/src/hotspot/share/runtime/sharedRuntime.cpp#L1021-L1028
> 
> However, with the scalarized calling convention, we have two unverified entry points (`verified_entry_point` and `verified_inline_entry_point`). Both need to be handled in `nmethod::inlinecache_check_contains`.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 540dab02
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/540dab026c3b09e4ed8fbec55c7907083494a7f5
Stats:     105 lines in 3 files changed: 102 ins; 2 del; 1 mod

8375086: [lworld] Implicit exception handling in inline-cache check is broken

Reviewed-by: chagedorn

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

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

From phubner at openjdk.org  Tue Feb  3 08:31:47 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 3 Feb 2026 08:31:47 GMT
Subject: [lworld] RFR: 8376221: [lworld] Do not store array of
 InlineLayoutInfo for all InstanceKlasses [v6]
In-Reply-To: <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>
References: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
 <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>
Message-ID: <_8hLjQu98oRiZ_PFbBg0DUQJA7kLDZMxBlPvaVsirdM=.9a97098d-f153-4bbb-a5bb-46b8c1389fe7@github.com>

On Mon, 2 Feb 2026 09:53:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Please refer to the JBS issue for a more detailed description of the background of this change. In summary, I suggest we only keep the array of InlineLayoutInfo for InstanceKlasses which need it, which are Klasses that have fields that have been inlined.
>> 
>> To make the transition to this easier, I suggest we change the following properties in FieldLayoutBuilder: 
>> 
>> _has_inline_type_fields
>> _has_flattening_information
>> 
>> to
>> 
>> _has_inlineable_fields
>> _has_inlined_fields
>> 
>> The `_has_inlineable_fields` property is only used for printing and `_has_inlined_fields` is the property we expose out to the ClassFileParser, telling us that this class has inlined fields, so the array of InlineLayoutInfo must be "preserved" and is possible to read from. Hence, the array is now only safe to access if `InstanceKlass::has_inlined_fields` is true, or simply if the actual field being accessed is flat (`fieldDescriptor::is_flat`).
>> 
>> I only found one place (in ciReplay.cpp) where we access the array of InlineLayoutInfo even though we might not have any inlined fields and only fields that are inlineable. I've changed this to use the normal "reference" path for fields that aren't flat.
>> 
>> Testing:
>> * Oracle's tier1-5, hotspot_valhalla and jdk_valhalla
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move InlineKlass::cast() to callers
>  - Add abstract check to field_is_inlineable

Marked as reviewed by phubner (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1966#pullrequestreview-3743801398

From thartmann at openjdk.org  Tue Feb  3 08:32:24 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 08:32:24 GMT
Subject: [lworld] RFR: 8375547: [lworld] Dependency verification fails with
 assert "Should have been marked for deoptimization"
Message-ID: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>

When detecting a mismatch in the calling convention, we call `super_method->set_mismatch()` out of the scope of the `Compile_lock`. When class loading/linking happens in parallel, other dependencies might be invalidated and nmethods will be marked for deoptimization. Verification code will then check that all nmethods that have violated dependencies have been marked. The verification will fail once it finds a nmethod that now has a violated dependency not due to the class loading but due to the mismatch that we just set.

Similar to how the [runtime handles similar situations](https://github.com/openjdk/valhalla/blob/2ad3ce1646bb5c717239f683686dd1034a9340c1/src/hotspot/share/oops/instanceKlass.cpp#L1230-L1235), `set_mismatch` needs to be performed while holding the lock. We then keep the lock until we marked all methods.

When looking at the code, I noticed that more instructions can be moved out of the scope of the lock, so I did that as well.

I quickly looked into creating a regression test for this but it's non-trivial. Also, our internal testing triggers this reliably, so I decided to go without a regression test for now.

Thanks,
Tobias

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

Commit messages:
 - More refactoring
 - Copyright
 - Merge branch 'lworld' into 8375546
 - JDK-8375547

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

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

From thartmann at openjdk.org  Tue Feb  3 08:58:42 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 08:58:42 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
Message-ID: <pbOPXSX9z9Po0smpg6gq1B1wDOvAOj3-URKe8EKM3ug=.54b1404d-fd4a-4266-9725-95b68e66b18c@github.com>

On Mon, 2 Feb 2026 23:03:40 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
>> 
>> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).
>
> Paul H?bner 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 13 additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>  - Missed obsolete test
>  - Years
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>  - substitutability contract changed
>  - Legacy handling in ProcessHandleImpl
>  - typo
>  - Test flags
>  - Dead stuff
>  - Merge branch 'JDK-8372954' of github.com:Arraying/valhalla into JDK-8372954
>  - ... and 3 more: https://git.openjdk.org/valhalla/compare/cd832afa...29344379

JIT changes look good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2012#pullrequestreview-3743937009

From thartmann at openjdk.org  Tue Feb  3 09:05:35 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 09:05:35 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
In-Reply-To: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
Message-ID: <NDy6klH9XMqRBt_avKw43JOoYOLkTxJYYDpco6oHxvQ=.2872d898-9733-4f98-8ce0-aa3df7ecaf8b@github.com>

On Mon, 2 Feb 2026 17:52:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
> 
> Please take a look and leave your review, thanks a lot.

That looks reasonable to me. Could you please try to re-enable the tests marked with `// TODO 8325632`? See my comment in [JDK-8325632](https://bugs.openjdk.org/browse/JDK-8325632) for details.

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

PR Review: https://git.openjdk.org/valhalla/pull/2016#pullrequestreview-3743976424

From qamai at openjdk.org  Tue Feb  3 09:27:31 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 09:27:31 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 [v2]
In-Reply-To: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
Message-ID: <-AR1HlbCUWfj8uROJxtGCwjPn7iOIPl_AqAGoNkTQ58=.92b8386b-c5d7-416e-afc3-58f600eb855e@github.com>

> Hi,
> 
> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
> 
> Please take a look and leave your review, thanks a lot.

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

  Enable tests from 8325632

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2016/files
  - new: https://git.openjdk.org/valhalla/pull/2016/files/1cbdd299..7e58fc3e

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

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

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

From thartmann at openjdk.org  Tue Feb  3 09:33:54 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 09:33:54 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 [v2]
In-Reply-To: <-AR1HlbCUWfj8uROJxtGCwjPn7iOIPl_AqAGoNkTQ58=.92b8386b-c5d7-416e-afc3-58f600eb855e@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
 <-AR1HlbCUWfj8uROJxtGCwjPn7iOIPl_AqAGoNkTQ58=.92b8386b-c5d7-416e-afc3-58f600eb855e@github.com>
Message-ID: <QG_4FoFyv1ACcTvzzb5qpL7Td_KJ6AJW1bi-lMSho3I=.f134954b-732a-4777-98cf-5b941e3da134@github.com>

On Tue, 3 Feb 2026 09:27:31 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
>> 
>> Please take a look and leave your review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable tests from 8325632

Thanks! Looks good to me (please re-run testing).

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2016#pullrequestreview-3744123320

From dsimms at openjdk.org  Tue Feb  3 09:35:14 2026
From: dsimms at openjdk.org (David Simms)
Date: Tue, 3 Feb 2026 09:35:14 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <--AC0E9ruoX3cAVBZq_c6qujs4fX9o4e45mWQhhIy6s=.945a9f92-5ada-40cb-915e-c37fc128c434@github.com>
References: <--AC0E9ruoX3cAVBZq_c6qujs4fX9o4e45mWQhhIy6s=.945a9f92-5ada-40cb-915e-c37fc128c434@github.com>
Message-ID: <18WO0-hAxMW8uYU_GzTuT8GV3eE52IK8F8P2WHkD394=.037c44fd-f906-4ed0-90f9-2207713b336b@github.com>

On Tue, 3 Feb 2026 06:35:28 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-27+6

This pull request has now been integrated.

Changeset: 5878735d
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5878735d40aed630eafb15f2242a88138359b5db
Stats:     13038 lines in 360 files changed: 8115 ins; 1842 del; 3081 mod

Merge

Merge jdk-27+6

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

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

From thartmann at openjdk.org  Tue Feb  3 09:56:35 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 09:56:35 GMT
Subject: [lworld] RFR: 8376059: [lworld] Aarch64: StoreLSpecial with 1 oop
 does not save register in pre-barrier [v2]
In-Reply-To: <FJQgSBJcWCcy7EyfOqSKNau1h9dprlCkORdH0pQLrDg=.67fa163e-8a7e-4936-9e62-b40546d3070f@github.com>
References: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
 <FJQgSBJcWCcy7EyfOqSKNau1h9dprlCkORdH0pQLrDg=.67fa163e-8a7e-4936-9e62-b40546d3070f@github.com>
Message-ID: <TS2R0IyLYTTx8gMN3NWmWPl4t2qZ3T9ZSvB7GLUtKWc=.4dfbfd55-2035-407c-bc1b-14ac7e395547@github.com>

On Mon, 2 Feb 2026 17:23:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Many thanks to @stefank for finding the issue and helping investigating it. This PR fixes a couple of issues:
>> 
>> - `g1StoreLSpecialOneOop` does not save `mem` and `src` during the GC pre-barrier, this risks clobber these values, which may lead to crashes or memory corruption when doing the store instruction.
>> - It seems that the value passed to the post-barrier should be an uncompressed oop, this requires us to decode the narrow oop instead of simply zero-extending it.
>> - Relax the restriction on the `src` register to be an arbitrary register.
>> - Split the rule into 2 so that we can avoid cloberring an additional register when the offset of the oop inside the payload is 0.
>> 
>> Testing:
>> - [x] tier1, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
>> - [x] tier1-4, valhalla-comp-stress, linux-aarch64
>> - [x] tier1-4, valhalla-comp-stress, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
>> 
>> 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:
> 
>  - Saving the register in the slow path instead
>  - recompute tmp4 instead of saving it

Looks good to me! I added a few minor comments.

I also took an Action Item to add `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0` and some more flags to our internal stress testing.

src/hotspot/cpu/aarch64/gc/g1/g1_aarch64.ad line 79:

> 77: // - Do no set/overwrite barrier data here, also handle G1C2BarrierPostNotNull
> 78: // - Move this into the .m4?
> 79: instruct g1StoreLSpecialOneOopOff0(indirect mem, iRegLNoSp src, immI0 off, iRegPNoSp tmp1, iRegPNoSp tmp2, iRegPNoSp tmp3, rFlagsReg cr)

Should we do the same on x64?

src/hotspot/cpu/aarch64/gc/g1/g1_aarch64.ad line 85:

> 83:   effect(TEMP tmp1, TEMP tmp2, TEMP tmp3, KILL cr);
> 84:   ins_cost(INSN_COST);
> 85:   format %{ "str  $src, $mem\t# g1StoreLSpecialOneOop" %}

The comment needs to be updated.

src/hotspot/cpu/aarch64/gc/g1/g1_aarch64.ad line 97:

> 95:     __ str($src$$Register, $mem$$Register);
> 96: 
> 97:     __ ubfm($tmp1$$Register, $src$$Register, 0, 31);

Please add a comment here.

src/hotspot/cpu/aarch64/gc/g1/g1_aarch64.ad line 119:

> 117: 
> 118:     // Adjust address to point to narrow oop
> 119:     __ add($tmp4$$Register, $mem$$Register, 4);

I think we should have asserts on `oop_off_1` and `oop_off_2` in `StoreFlatNode::expand_atomic` that check that `off` is either zero or four. Otherwise we would hit a "bad ad file" failure during matching. Also, a comment explaining that this is due to alignment constraints would be nice.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2013#pullrequestreview-3744076946
PR Review Comment: https://git.openjdk.org/valhalla/pull/2013#discussion_r2758083421
PR Review Comment: https://git.openjdk.org/valhalla/pull/2013#discussion_r2758085788
PR Review Comment: https://git.openjdk.org/valhalla/pull/2013#discussion_r2758209368
PR Review Comment: https://git.openjdk.org/valhalla/pull/2013#discussion_r2758150042

From thartmann at openjdk.org  Tue Feb  3 10:08:47 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 10:08:47 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer
In-Reply-To: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
Message-ID: <FLFzROkifCOzysZrb14WLUtgV1JFRYzPhBEAr-Esicw=.8c4e860f-c50c-4904-a19b-3ae51c40c77a@github.com>

On Mon, 2 Feb 2026 23:34:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...

Just a few drive-by comments: Isn't this API heavily used by the Vector API branch in Valhalla? And wouldn't array flattening always be a VM decision (some platforms might not even implement it)?

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3840324005

From qamai at openjdk.org  Tue Feb  3 11:15:58 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 11:15:58 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 [v2]
In-Reply-To: <-AR1HlbCUWfj8uROJxtGCwjPn7iOIPl_AqAGoNkTQ58=.92b8386b-c5d7-416e-afc3-58f600eb855e@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
 <-AR1HlbCUWfj8uROJxtGCwjPn7iOIPl_AqAGoNkTQ58=.92b8386b-c5d7-416e-afc3-58f600eb855e@github.com>
Message-ID: <TsRbyOFTPCK2_pAiR3uo1ew81rTkB480YbxXgkPmwCc=.381e30cb-ca0a-4d38-8369-e8d87bacab0a@github.com>

On Tue, 3 Feb 2026 09:27:31 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
>> 
>> Please take a look and leave your review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable tests from 8325632

There seems to be a bunch of timeouts when enabling the tests in `TestNullableInlineTypes`, which is pretty understandable given the enabled tests run 1000 iterations each time they are invoked. I think I will keep them disabled and only enable the test in `TestNullableArrays` first.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2016#issuecomment-3840679449

From mchevalier at openjdk.org  Tue Feb  3 11:30:53 2026
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 3 Feb 2026 11:30:53 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v2]
In-Reply-To: <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <o04pcdsUHYUmnrBXoGMAw_-7HD4jF0QTKUb3SVVGSjM=.4127cdaf-15e5-48ce-8506-893fa17f22e2@github.com>
 <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>
Message-ID: <dS-CUAFcztZ5lTF_hG_P6_cnqMrkMlsUh-j0xGD6cRY=.9552e3b7-9309-4f46-a095-fb38d167d983@github.com>

On Mon, 2 Feb 2026 16:33:05 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Details
>>  - exception handling
>>  - oops
>>  - Also cache correctly whole stable fields
>>  - fix comment
>>  - Remove debug
>>  - ShouldNotReachHere
>>  - explicit casts
>>  - Clean up
>>  - expand_constant
>
> src/hotspot/share/ci/ciInstance.cpp line 154:
> 
>> 152:     return ciConstant();
>> 153:   }
>> 154:   if (field->original_holder() == nullptr) {
> 
> I think simply comparing `field` and `containing_field` is enough.

I thought too, but then, I was surprised.

For instance from `GraphBuilder::access_field` (that does `ciConstant field_value = field->constant_value_of(const_oop);`), we get the field from `ciField* field = stream()->get_field(will_link);`. Deep inside, the field is created in `ciField* ciEnv::get_field_by_index_impl(ciInstanceKlass* accessor, int index, Bytecodes::Code bc)` and put in the `field_cache` (whose role is not clear to me). The interesting part is that it's a field created here.

And later, when the fields are computed by `void ciInstanceKlass::compute_nonstatic_fields()`, new `ciField` objects are created, but the field_cache ones aren't reused. In such a case, I get a `field` and `containing_field` that have identical content but with different pointers. If I simply compare the pointers, the `field` is wrongly interpreted as a sub-field of `containing_field`. I guess I could compare their symbols (since offset and signatures might not be enough), but that doesn't seem much better to me.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2758606244

From thartmann at openjdk.org  Tue Feb  3 11:30:58 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 11:30:58 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 [v2]
In-Reply-To: <-AR1HlbCUWfj8uROJxtGCwjPn7iOIPl_AqAGoNkTQ58=.92b8386b-c5d7-416e-afc3-58f600eb855e@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
 <-AR1HlbCUWfj8uROJxtGCwjPn7iOIPl_AqAGoNkTQ58=.92b8386b-c5d7-416e-afc3-58f600eb855e@github.com>
Message-ID: <8RHkOLZjKKCaB6-Tau6D8zgL40e2_TLoSCokFO9KMXI=.7514266f-50eb-4597-b0a4-109a921ca1b0@github.com>

On Tue, 3 Feb 2026 09:27:31 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
>> 
>> Please take a look and leave your review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable tests from 8325632

Okay, sounds good. Maybe we should then just reduce the warmup iterations for those tests.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2016#issuecomment-3840756998

From jsikstro at openjdk.org  Tue Feb  3 11:43:25 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 3 Feb 2026 11:43:25 GMT
Subject: [lworld] RFR: 8376221: [lworld] Do not store array of
 InlineLayoutInfo for all InstanceKlasses [v6]
In-Reply-To: <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>
References: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
 <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>
Message-ID: <qCtc-bUmLsQn61ko5Qxk2Y2TBBoXJufDXXQIDXYKsu8=.2d2a7aa3-2fb4-455d-a7a6-8a1fb5dc3ad1@github.com>

On Mon, 2 Feb 2026 09:53:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Please refer to the JBS issue for a more detailed description of the background of this change. In summary, I suggest we only keep the array of InlineLayoutInfo for InstanceKlasses which need it, which are Klasses that have fields that have been inlined.
>> 
>> To make the transition to this easier, I suggest we change the following properties in FieldLayoutBuilder: 
>> 
>> _has_inline_type_fields
>> _has_flattening_information
>> 
>> to
>> 
>> _has_inlineable_fields
>> _has_inlined_fields
>> 
>> The `_has_inlineable_fields` property is only used for printing and `_has_inlined_fields` is the property we expose out to the ClassFileParser, telling us that this class has inlined fields, so the array of InlineLayoutInfo must be "preserved" and is possible to read from. Hence, the array is now only safe to access if `InstanceKlass::has_inlined_fields` is true, or simply if the actual field being accessed is flat (`fieldDescriptor::is_flat`).
>> 
>> I only found one place (in ciReplay.cpp) where we access the array of InlineLayoutInfo even though we might not have any inlined fields and only fields that are inlineable. I've changed this to use the normal "reference" path for fields that aren't flat.
>> 
>> Testing:
>> * Oracle's tier1-5, hotspot_valhalla and jdk_valhalla
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move InlineKlass::cast() to callers
>  - Add abstract check to field_is_inlineable

Thank you for the reviews everyone! I merged with the tip of lworld and reran tier1-4 which is green. The failing test in GHA is due to an unrelated issue (solved in [JDK-8376358](https://bugs.openjdk.org/browse/JDK-8376358)).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1966#issuecomment-3840812186

From duke at openjdk.org  Tue Feb  3 11:46:29 2026
From: duke at openjdk.org (duke)
Date: Tue, 3 Feb 2026 11:46:29 GMT
Subject: [lworld] RFR: 8376221: [lworld] Do not store array of
 InlineLayoutInfo for all InstanceKlasses [v6]
In-Reply-To: <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>
References: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
 <kheKtvifr-9dnXhTp3h_MY5c78yK0bVVYM-7m7dqv8g=.3594252f-ec7c-49bd-a0e4-225af90bc0e4@github.com>
Message-ID: <18nrGlFI_YSUZWJ_vF27NLY2US06Fu7ZJTkn1Eg-q6g=.7f4b8401-693a-4844-8725-4179053a57b9@github.com>

On Mon, 2 Feb 2026 09:53:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Please refer to the JBS issue for a more detailed description of the background of this change. In summary, I suggest we only keep the array of InlineLayoutInfo for InstanceKlasses which need it, which are Klasses that have fields that have been inlined.
>> 
>> To make the transition to this easier, I suggest we change the following properties in FieldLayoutBuilder: 
>> 
>> _has_inline_type_fields
>> _has_flattening_information
>> 
>> to
>> 
>> _has_inlineable_fields
>> _has_inlined_fields
>> 
>> The `_has_inlineable_fields` property is only used for printing and `_has_inlined_fields` is the property we expose out to the ClassFileParser, telling us that this class has inlined fields, so the array of InlineLayoutInfo must be "preserved" and is possible to read from. Hence, the array is now only safe to access if `InstanceKlass::has_inlined_fields` is true, or simply if the actual field being accessed is flat (`fieldDescriptor::is_flat`).
>> 
>> I only found one place (in ciReplay.cpp) where we access the array of InlineLayoutInfo even though we might not have any inlined fields and only fields that are inlineable. I've changed this to use the normal "reference" path for fields that aren't flat.
>> 
>> Testing:
>> * Oracle's tier1-5, hotspot_valhalla and jdk_valhalla
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move InlineKlass::cast() to callers
>  - Add abstract check to field_is_inlineable

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1966#issuecomment-3840823160

From heidinga at openjdk.org  Tue Feb  3 12:10:11 2026
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 3 Feb 2026 12:10:11 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
Message-ID: <QHHx6pKwlDcJRMCM0fVBBedNCQwgCEOZ5mAPyTv1iLg=.f10ef6ac-6f83-471d-86aa-d2fd1726ee6f@github.com>

On Mon, 2 Feb 2026 23:03:40 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
>> 
>> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).
>
> Paul H?bner 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 13 additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>  - Missed obsolete test
>  - Years
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>  - substitutability contract changed
>  - Legacy handling in ProcessHandleImpl
>  - typo
>  - Test flags
>  - Dead stuff
>  - Merge branch 'JDK-8372954' of github.com:Arraying/valhalla into JDK-8372954
>  - ... and 3 more: https://git.openjdk.org/valhalla/compare/f3a1a179...29344379

Apart from adding the comment, this looks good to me

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

> 1397:   // one for the field the JVM injects when detecting an empty inline class
> 1398:   const int total_fields = length + num_injected + (is_inline_type ? 2 : 0)
> 1399:                            + (is_value_class ? 1 : 0);

Can you update the comment block above to include something like:

// all value classes, even abstract ones, get an additional slot for the acmp_maps field used by the substitutability check


We need something to make it clear why we're testing both inline type and value class here and what the new field is

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

PR Review: https://git.openjdk.org/valhalla/pull/2012#pullrequestreview-3744873855
PR Review Comment: https://git.openjdk.org/valhalla/pull/2012#discussion_r2758735750

From jsikstro at openjdk.org  Tue Feb  3 12:23:56 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 3 Feb 2026 12:23:56 GMT
Subject: [lworld] Integrated: 8376221: [lworld] Do not store array of
 InlineLayoutInfo for all InstanceKlasses
In-Reply-To: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
References: <HaxqxDClb_t-J9O8RUBfVSeRyGAmpf6H7OOqAGiRrwc=.3b4ed841-5891-4548-b921-045eb2b97cb6@github.com>
Message-ID: <CzlwXB56eqjufFWJuVCA67rDxirAiFDFNy5Pxt8bVGk=.0abdb6ce-79a9-43e6-a78e-393756bde1e1@github.com>

On Mon, 26 Jan 2026 08:43:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> Please refer to the JBS issue for a more detailed description of the background of this change. In summary, I suggest we only keep the array of InlineLayoutInfo for InstanceKlasses which need it, which are Klasses that have fields that have been inlined.
> 
> To make the transition to this easier, I suggest we change the following properties in FieldLayoutBuilder: 
> 
> _has_inline_type_fields
> _has_flattening_information
> 
> to
> 
> _has_inlineable_fields
> _has_inlined_fields
> 
> The `_has_inlineable_fields` property is only used for printing and `_has_inlined_fields` is the property we expose out to the ClassFileParser, telling us that this class has inlined fields, so the array of InlineLayoutInfo must be "preserved" and is possible to read from. Hence, the array is now only safe to access if `InstanceKlass::has_inlined_fields` is true, or simply if the actual field being accessed is flat (`fieldDescriptor::is_flat`).
> 
> I only found one place (in ciReplay.cpp) where we access the array of InlineLayoutInfo even though we might not have any inlined fields and only fields that are inlineable. I've changed this to use the normal "reference" path for fields that aren't flat.
> 
> Testing:
> * Oracle's tier1-5, hotspot_valhalla and jdk_valhalla

This pull request has now been integrated.

Changeset: 53c55318
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
Committer: Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/53c55318228dabef79be8939f50a3d686f752b3b
Stats:     156 lines in 11 files changed: 75 ins; 28 del; 53 mod

8376221: [lworld] Do not store array of InlineLayoutInfo for all InstanceKlasses

Reviewed-by: phubner, fparain

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

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

From mchevalier at openjdk.org  Tue Feb  3 12:38:10 2026
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 3 Feb 2026 12:38:10 GMT
Subject: [lworld] RFR: 8375547: [lworld] Dependency verification fails with
 assert "Should have been marked for deoptimization"
In-Reply-To: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
References: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
Message-ID: <wjquy2JtyTI_KnEDIIfUUDfU2Q9SyOopoYCA_UF94hU=.697502b5-0f0c-4d99-b3ea-ab1057be577c@github.com>

On Mon, 2 Feb 2026 15:44:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When detecting a mismatch in the calling convention, we call `super_method->set_mismatch()` out of the scope of the `Compile_lock`. When class loading/linking happens in parallel, other dependencies might be invalidated and nmethods will be marked for deoptimization. Verification code will then check that all nmethods that have violated dependencies have been marked. The verification will fail once it finds a nmethod that now has a violated dependency not due to the class loading but due to the mismatch that we just set.
> 
> Similar to how the [runtime handles similar situations](https://github.com/openjdk/valhalla/blob/2ad3ce1646bb5c717239f683686dd1034a9340c1/src/hotspot/share/oops/instanceKlass.cpp#L1230-L1235), `set_mismatch` needs to be performed while holding the lock. We then keep the lock until we marked all methods.
> 
> When looking at the code, I noticed that more instructions can be moved out of the scope of the lock, so I did that as well.
> 
> I quickly looked into creating a regression test for this but it's non-trivial. Also, our internal testing triggers this reliably, so I decided to go without a regression test for now.
> 
> Thanks,
> Tobias

Seems reasonable. As far as I can tell, I think what is not in the lock scope is fine. And I've checked it's the only place we use `Method::set_mismatch()`.

src/hotspot/share/runtime/sharedRuntime.cpp line 2943:

> 2941:                   methodHandle mh(thread, super_method);
> 2942:                   DeoptimizationScope deopt_scope;
> 2943:                   {

Maybe one could put a comment on the block start, stating that's it's to limit the scope of the MutexLocker. I've seen such pattern, so it's possible that I'd guess it out of context, but uncertain. I've seen some blocks whose purpose were sometimes unclear (either to allow to shadow variables, or maybe a leftover of some control structure).

But maybe I'm being over cautious, and documenting a common pattern is not worth the noise. I'm not convinced myself. Feel free to ignore.

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

Marked as reviewed by mchevalier (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2014#pullrequestreview-3744995441
PR Review Comment: https://git.openjdk.org/valhalla/pull/2014#discussion_r2758843106

From qamai at openjdk.org  Tue Feb  3 12:53:39 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 12:53:39 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 [v3]
In-Reply-To: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
Message-ID: <jpgAm0xEv4CcytNdC23dtyQdC_fNcDtRIAUPYYQ3EjE=.4913fed1-c95e-4f66-b502-5a052c4a0b7a@github.com>

> Hi,
> 
> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
> 
> Please take a look and leave your review, thanks a lot.

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

  Disable tests in NullableInlineTypes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2016/files
  - new: https://git.openjdk.org/valhalla/pull/2016/files/7e58fc3e..1501c850

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

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

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

From qamai at openjdk.org  Tue Feb  3 12:57:09 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 12:57:09 GMT
Subject: [lworld] RFR: 8376059: [lworld] Fix the issues in code generation
 of StoreLSpecialNode [v3]
In-Reply-To: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
References: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
Message-ID: <-AGw9FyRm61va62-PmJ_VOhkI9QJrxx-iCFJ8K45dCU=.4f2954f8-a75c-4989-9d7f-425cef2a3c20@github.com>

> Hi,
> 
> Many thanks to @stefank for finding the issue and helping investigating it. This PR fixes a couple of issues:
> 
> - On Aarch64, `g1StoreLSpecialOneOop` does not save `mem` and `src` during the GC pre-barrier, this risks clobber these values, which may lead to crashes or memory corruption when doing the store instruction.
> - It seems that the value passed to the post-barrier should be an uncompressed oop, this requires us to decode the narrow oop instead of simply zero-extending it.
> - Relax the restriction on the `src` register to be an arbitrary register.
> - Split the rule into 2 so that we can avoid cloberring an additional register on Aarch64 when the offset of the oop inside the payload is 0, it also makes the implementation a little easier to read.
> 
> Testing:
> - [x] tier1-4, valhalla-comp-stress, linux-aarch64
> - [x] tier1-4, valhalla-comp-stress, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
> - [ ] tier1-4, valhalla-comp-stress, linux-x64
> - [ ] tier1-4, valhalla-comp-stress, linux-x64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
> 
> Please take a look and leave your reviews, thanks a lot.

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

  Fix x64, add assert in StoreFlatNode::expand_atomic

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2013/files
  - new: https://git.openjdk.org/valhalla/pull/2013/files/fb475fc6..a9978bf0

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

  Stats: 68 lines in 3 files changed: 42 ins; 8 del; 18 mod
  Patch: https://git.openjdk.org/valhalla/pull/2013.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2013/head:pull/2013

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

From qamai at openjdk.org  Tue Feb  3 12:59:06 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 12:59:06 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 [v3]
In-Reply-To: <jpgAm0xEv4CcytNdC23dtyQdC_fNcDtRIAUPYYQ3EjE=.4913fed1-c95e-4f66-b502-5a052c4a0b7a@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
 <jpgAm0xEv4CcytNdC23dtyQdC_fNcDtRIAUPYYQ3EjE=.4913fed1-c95e-4f66-b502-5a052c4a0b7a@github.com>
Message-ID: <wUImETVPf1g6838P1Rw8xY-T5_7TxnOUOpfI7f9PDsI=.412e783d-3f0f-4d1f-ac51-6ff34c79f56d@github.com>

On Tue, 3 Feb 2026 12:53:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
>> 
>> Please take a look and leave your review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable tests in NullableInlineTypes

I notice there are other tests in this file that run for thousands of iteration each time they are invoked, so I created https://bugs.openjdk.org/browse/JDK-8377066 to track them. For this PR, I disable the test in `TestNullableInlineTypes`.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2016#issuecomment-3841149300

From qamai at openjdk.org  Tue Feb  3 13:09:06 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 13:09:06 GMT
Subject: [lworld] RFR: 8376059: [lworld] Fix the issues in code generation
 of StoreLSpecialNode [v2]
In-Reply-To: <TS2R0IyLYTTx8gMN3NWmWPl4t2qZ3T9ZSvB7GLUtKWc=.4dfbfd55-2035-407c-bc1b-14ac7e395547@github.com>
References: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
 <FJQgSBJcWCcy7EyfOqSKNau1h9dprlCkORdH0pQLrDg=.67fa163e-8a7e-4936-9e62-b40546d3070f@github.com>
 <TS2R0IyLYTTx8gMN3NWmWPl4t2qZ3T9ZSvB7GLUtKWc=.4dfbfd55-2035-407c-bc1b-14ac7e395547@github.com>
Message-ID: <nZMLQb1ojLr3glYqFZjZ1NCxaX31Y5sYVMIrRpD9d0Y=.8091164f-caeb-4aed-b293-9a6db5f3846f@github.com>

On Tue, 3 Feb 2026 09:22:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Saving the register in the slow path instead
>>  - recompute tmp4 instead of saving it
>
> src/hotspot/cpu/aarch64/gc/g1/g1_aarch64.ad line 79:
> 
>> 77: // - Do no set/overwrite barrier data here, also handle G1C2BarrierPostNotNull
>> 78: // - Move this into the .m4?
>> 79: instruct g1StoreLSpecialOneOopOff0(indirect mem, iRegLNoSp src, immI0 off, iRegPNoSp tmp1, iRegPNoSp tmp2, iRegPNoSp tmp3, rFlagsReg cr)
> 
> Should we do the same on x64?

Yes you are right, I have fixed these issues on x64, too.

> src/hotspot/cpu/aarch64/gc/g1/g1_aarch64.ad line 119:
> 
>> 117: 
>> 118:     // Adjust address to point to narrow oop
>> 119:     __ add($tmp4$$Register, $mem$$Register, 4);
> 
> I think we should have asserts on `oop_off_1` and `oop_off_2` in `StoreFlatNode::expand_atomic` that check that `off` is either zero or four. Otherwise we would hit a "bad ad file" failure during matching. Also, a comment explaining that this is due to alignment constraints would be nice.

Done

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2013#discussion_r2758983892
PR Review Comment: https://git.openjdk.org/valhalla/pull/2013#discussion_r2758985511

From fyang at openjdk.org  Tue Feb  3 13:11:44 2026
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Feb 2026 13:11:44 GMT
Subject: [lworld] RFR: 8377065: [lworld] Fix merge removing
 VM_Version::supports_fast_class_init_checks() check
Message-ID: <CCKjH98DTmCDQMfzxssZaWE0dEPsLzp-7R37odiLmiw=.92ea7539-ba0a-4808-bcac-96cd9699ef9f@github.com>

Hi,

Please consider this small change fixing a minor issue in latest merge.
The original issue is: https://bugs.openjdk.org/browse/JDK-8370112.
After the latest merge, there is still one runtime check for `VM_Version::supports_fast_class_init_checks()` left in x86 and aarch64 platform specific code.
We should replace them with asserts for consistency with other places. Verified by running `hotspot_valhalla` and `jdk_valhalla` on these two platforms.

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

Commit messages:
 - 8377065: [lworld] Fix merge removing VM_Version::supports_fast_class_init_checks() check

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

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

From vromero at openjdk.org  Tue Feb  3 13:38:25 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 13:38:25 GMT
Subject: RFR: Remove redundant null checks [v8]
In-Reply-To: <QQN4FJdzZICZcAoClCB0S8TGELFPR0jiVQZVu70xklc=.2cd9da7c-c247-4dbb-8568-f95814fc7bd4@github.com>
References: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
 <IJuNFbMZkBJjyU3fM3hQd-FdIDy9OZIHKycItDG4TN8=.2a9a014c-2eef-4151-a076-82f51242478f@github.com>
 <QQN4FJdzZICZcAoClCB0S8TGELFPR0jiVQZVu70xklc=.2cd9da7c-c247-4dbb-8568-f95814fc7bd4@github.com>
Message-ID: <g_SznvHccDOQvrtYlzTBfc4f4xUo_RfIINcU3ZmkCog=.803cecd5-ff7d-4453-ac92-702b7b690de3@github.com>

On Mon, 26 Jan 2026 11:27:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero 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 12 additional commits since the last revision:
>> 
>>  - Merge branch 'bworld' into remove.redundant.null.checks
>>  - minor change
>>  - addressing review comments
>>  - adding test cases
>>  - adding more tests
>>  - adding more tests
>>  - minor change
>>  - another change
>>  - regression tests
>>  - remove redundant null checks
>>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/f3c0d0a9...37939f06
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 218:
> 
>> 216: 
>> 217:     public void visitTypeCast(JCTypeCast tree) {
>> 218:         boolean generateNullCheck = tree.strict;
> 
> Not sure this is still required -- `Attr` will filter this out anyway?

yep I removed this code and modified the one in Attr a bit

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1947#discussion_r2759125516

From thartmann at openjdk.org  Tue Feb  3 13:53:43 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 13:53:43 GMT
Subject: [lworld] RFR: 8375547: [lworld] Dependency verification fails with
 assert "Should have been marked for deoptimization" [v2]
In-Reply-To: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
References: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
Message-ID: <uGN3xEjWaxsnMEWGFML4FfSQI7AunuGZLHSDCQg1q48=.91066365-41a1-42a2-b0e6-948b674bc02e@github.com>

> When detecting a mismatch in the calling convention, we call `super_method->set_mismatch()` out of the scope of the `Compile_lock`. When class loading/linking happens in parallel, other dependencies might be invalidated and nmethods will be marked for deoptimization. Verification code will then check that all nmethods that have violated dependencies have been marked. The verification will fail once it finds a nmethod that now has a violated dependency not due to the class loading but due to the mismatch that we just set.
> 
> Similar to how the [runtime handles similar situations](https://github.com/openjdk/valhalla/blob/2ad3ce1646bb5c717239f683686dd1034a9340c1/src/hotspot/share/oops/instanceKlass.cpp#L1230-L1235), `set_mismatch` needs to be performed while holding the lock. We then keep the lock until we marked all methods.
> 
> When looking at the code, I noticed that more instructions can be moved out of the scope of the lock, so I did that as well.
> 
> I quickly looked into creating a regression test for this but it's non-trivial. Also, our internal testing triggers this reliably, so I decided to go without a regression test for now.
> 
> Thanks,
> Tobias

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

  Nice comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2014/files
  - new: https://git.openjdk.org/valhalla/pull/2014/files/66552db9..79be6198

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

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

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

From thartmann at openjdk.org  Tue Feb  3 13:53:44 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 13:53:44 GMT
Subject: [lworld] RFR: 8375547: [lworld] Dependency verification fails with
 assert "Should have been marked for deoptimization" [v2]
In-Reply-To: <uGN3xEjWaxsnMEWGFML4FfSQI7AunuGZLHSDCQg1q48=.91066365-41a1-42a2-b0e6-948b674bc02e@github.com>
References: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
 <uGN3xEjWaxsnMEWGFML4FfSQI7AunuGZLHSDCQg1q48=.91066365-41a1-42a2-b0e6-948b674bc02e@github.com>
Message-ID: <ToL6Tx1h-ILLmqHxGV0D9Gzhrgq_jgkSCwSocYV1JbQ=.bf41ab15-48be-4be0-954b-3fa483c40194@github.com>

On Tue, 3 Feb 2026 13:50:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> When detecting a mismatch in the calling convention, we call `super_method->set_mismatch()` out of the scope of the `Compile_lock`. When class loading/linking happens in parallel, other dependencies might be invalidated and nmethods will be marked for deoptimization. Verification code will then check that all nmethods that have violated dependencies have been marked. The verification will fail once it finds a nmethod that now has a violated dependency not due to the class loading but due to the mismatch that we just set.
>> 
>> Similar to how the [runtime handles similar situations](https://github.com/openjdk/valhalla/blob/2ad3ce1646bb5c717239f683686dd1034a9340c1/src/hotspot/share/oops/instanceKlass.cpp#L1230-L1235), `set_mismatch` needs to be performed while holding the lock. We then keep the lock until we marked all methods.
>> 
>> When looking at the code, I noticed that more instructions can be moved out of the scope of the lock, so I did that as well.
>> 
>> I quickly looked into creating a regression test for this but it's non-trivial. Also, our internal testing triggers this reliably, so I decided to go without a regression test for now.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Nice comments

Thanks for the review Marc. I added a comment.

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

PR Review: https://git.openjdk.org/valhalla/pull/2014#pullrequestreview-3745389015

From thartmann at openjdk.org  Tue Feb  3 13:53:47 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 13:53:47 GMT
Subject: [lworld] RFR: 8375547: [lworld] Dependency verification fails with
 assert "Should have been marked for deoptimization" [v2]
In-Reply-To: <wjquy2JtyTI_KnEDIIfUUDfU2Q9SyOopoYCA_UF94hU=.697502b5-0f0c-4d99-b3ea-ab1057be577c@github.com>
References: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
 <wjquy2JtyTI_KnEDIIfUUDfU2Q9SyOopoYCA_UF94hU=.697502b5-0f0c-4d99-b3ea-ab1057be577c@github.com>
Message-ID: <BIqv_bI9S4R6ZPYH6Y7esB5zwCbZUW_ddk1H0XLhMnE=.a380acf1-8dd5-45ba-9140-6842e55251e5@github.com>

On Tue, 3 Feb 2026 12:31:59 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Nice comments
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 2943:
> 
>> 2941:                   methodHandle mh(thread, super_method);
>> 2942:                   DeoptimizationScope deopt_scope;
>> 2943:                   {
> 
> Maybe one could put a comment on the block start, stating that's it's to limit the scope of the MutexLocker. I've seen such pattern, so it's possible that I'd guess it out of context, but uncertain. I've seen some blocks whose purpose were sometimes unclear (either to allow to shadow variables, or maybe a leftover of some control structure).
> 
> But maybe I'm being over cautious, and documenting a common pattern is not worth the noise. I'm not convinced myself. Feel free to ignore.

I think comments are always good. What about this?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2014#discussion_r2759184416

From thartmann at openjdk.org  Tue Feb  3 13:56:33 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 13:56:33 GMT
Subject: [lworld] RFR: 8376059: [lworld] Fix the issues in code generation
 of StoreLSpecialNode [v3]
In-Reply-To: <-AGw9FyRm61va62-PmJ_VOhkI9QJrxx-iCFJ8K45dCU=.4f2954f8-a75c-4989-9d7f-425cef2a3c20@github.com>
References: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
 <-AGw9FyRm61va62-PmJ_VOhkI9QJrxx-iCFJ8K45dCU=.4f2954f8-a75c-4989-9d7f-425cef2a3c20@github.com>
Message-ID: <mP7sDzs0QV_6bPX4wQaQF1llO5otUWIeFplGcqj-ohE=.4177b266-253f-4222-b8df-8fc746e72ded@github.com>

On Tue, 3 Feb 2026 12:57:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Many thanks to @stefank for finding the issue and helping investigating it. This PR fixes a couple of issues:
>> 
>> - On Aarch64, `g1StoreLSpecialOneOop` does not save `mem` and `src` during the GC pre-barrier, this risks clobber these values, which may lead to crashes or memory corruption when doing the store instruction.
>> - It seems that the value passed to the post-barrier should be an uncompressed oop, this requires us to decode the narrow oop instead of simply zero-extending it.
>> - Relax the restriction on the `src` register to be an arbitrary register.
>> - Split the rule into 2 so that we can avoid cloberring an additional register on Aarch64 when the offset of the oop inside the payload is 0, it also makes the implementation a little easier to read.
>> 
>> Testing:
>> - [x] tier1-4, valhalla-comp-stress, linux-aarch64
>> - [x] tier1-4, valhalla-comp-stress, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
>> - [x] tier1-4, valhalla-comp-stress, linux-x64
>> - [x] tier1-4, valhalla-comp-stress, linux-x64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix x64, add assert in StoreFlatNode::expand_atomic

Thanks, that looks good to me!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2013#pullrequestreview-3745415034

From thartmann at openjdk.org  Tue Feb  3 13:57:41 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 13:57:41 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 [v3]
In-Reply-To: <jpgAm0xEv4CcytNdC23dtyQdC_fNcDtRIAUPYYQ3EjE=.4913fed1-c95e-4f66-b502-5a052c4a0b7a@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
 <jpgAm0xEv4CcytNdC23dtyQdC_fNcDtRIAUPYYQ3EjE=.4913fed1-c95e-4f66-b502-5a052c4a0b7a@github.com>
Message-ID: <fP5TDJ_-ie-Sa7v9j708jtxx91qfg5dA99JK8etmMug=.601b8337-ff0b-47d9-8cb4-c9697f4ccda5@github.com>

On Tue, 3 Feb 2026 12:53:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
>> 
>> Please take a look and leave your review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable tests in NullableInlineTypes

Marked as reviewed by thartmann (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/2016#pullrequestreview-3745419963

From mchevalier at openjdk.org  Tue Feb  3 13:59:48 2026
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 3 Feb 2026 13:59:48 GMT
Subject: [lworld] RFR: 8375547: [lworld] Dependency verification fails with
 assert "Should have been marked for deoptimization" [v2]
In-Reply-To: <uGN3xEjWaxsnMEWGFML4FfSQI7AunuGZLHSDCQg1q48=.91066365-41a1-42a2-b0e6-948b674bc02e@github.com>
References: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
 <uGN3xEjWaxsnMEWGFML4FfSQI7AunuGZLHSDCQg1q48=.91066365-41a1-42a2-b0e6-948b674bc02e@github.com>
Message-ID: <cten_TGXLgKTBXc76AyRgPJfwYVFlMTKMM40mtl8x5U=.d65567a3-f1f0-4e3e-8ca6-c7eaf8977677@github.com>

On Tue, 3 Feb 2026 13:53:43 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> When detecting a mismatch in the calling convention, we call `super_method->set_mismatch()` out of the scope of the `Compile_lock`. When class loading/linking happens in parallel, other dependencies might be invalidated and nmethods will be marked for deoptimization. Verification code will then check that all nmethods that have violated dependencies have been marked. The verification will fail once it finds a nmethod that now has a violated dependency not due to the class loading but due to the mismatch that we just set.
>> 
>> Similar to how the [runtime handles similar situations](https://github.com/openjdk/valhalla/blob/2ad3ce1646bb5c717239f683686dd1034a9340c1/src/hotspot/share/oops/instanceKlass.cpp#L1230-L1235), `set_mismatch` needs to be performed while holding the lock. We then keep the lock until we marked all methods.
>> 
>> When looking at the code, I noticed that more instructions can be moved out of the scope of the lock, so I did that as well.
>> 
>> I quickly looked into creating a regression test for this but it's non-trivial. Also, our internal testing triggers this reliably, so I decided to go without a regression test for now.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Nice comments

Fine with me! Between this and the PR description if one has more wonders, I'm happy.

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

Marked as reviewed by mchevalier (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2014#pullrequestreview-3745430953

From thartmann at openjdk.org  Tue Feb  3 14:04:57 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 14:04:57 GMT
Subject: [lworld] RFR: 8375547: [lworld] Dependency verification fails with
 assert "Should have been marked for deoptimization" [v2]
In-Reply-To: <uGN3xEjWaxsnMEWGFML4FfSQI7AunuGZLHSDCQg1q48=.91066365-41a1-42a2-b0e6-948b674bc02e@github.com>
References: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
 <uGN3xEjWaxsnMEWGFML4FfSQI7AunuGZLHSDCQg1q48=.91066365-41a1-42a2-b0e6-948b674bc02e@github.com>
Message-ID: <BFV5XzfbJUBEG42baACbJvq3INXSLZBFH_hUmhY5QWk=.13a7fee8-d138-47e3-b524-873dd7ff1055@github.com>

On Tue, 3 Feb 2026 13:53:43 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> When detecting a mismatch in the calling convention, we call `super_method->set_mismatch()` out of the scope of the `Compile_lock`. When class loading/linking happens in parallel, other dependencies might be invalidated and nmethods will be marked for deoptimization. Verification code will then check that all nmethods that have violated dependencies have been marked. The verification will fail once it finds a nmethod that now has a violated dependency not due to the class loading but due to the mismatch that we just set.
>> 
>> Similar to how the [runtime handles similar situations](https://github.com/openjdk/valhalla/blob/2ad3ce1646bb5c717239f683686dd1034a9340c1/src/hotspot/share/oops/instanceKlass.cpp#L1230-L1235), `set_mismatch` needs to be performed while holding the lock. We then keep the lock until we marked all methods.
>> 
>> When looking at the code, I noticed that more instructions can be moved out of the scope of the lock, so I did that as well.
>> 
>> I quickly looked into creating a regression test for this but it's non-trivial. Also, our internal testing triggers this reliably, so I decided to go without a regression test for now.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Nice comments

Thanks Marc!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2014#issuecomment-3841499400

From fparain at openjdk.org  Tue Feb  3 14:08:19 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 3 Feb 2026 14:08:19 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <QHHx6pKwlDcJRMCM0fVBBedNCQwgCEOZ5mAPyTv1iLg=.f10ef6ac-6f83-471d-86aa-d2fd1726ee6f@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
 <QHHx6pKwlDcJRMCM0fVBBedNCQwgCEOZ5mAPyTv1iLg=.f10ef6ac-6f83-471d-86aa-d2fd1726ee6f@github.com>
Message-ID: <RDdI9sRucsKaQM3DZSDhZF2mWoZQKBrYI4Y2R_dsbsE=.7a13953b-8f07-4de5-850c-0c0bc8718403@github.com>

On Tue, 3 Feb 2026 12:02:41 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Paul H?bner 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 13 additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>>  - Missed obsolete test
>>  - Years
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>>  - substitutability contract changed
>>  - Legacy handling in ProcessHandleImpl
>>  - typo
>>  - Test flags
>>  - Dead stuff
>>  - Merge branch 'JDK-8372954' of github.com:Arraying/valhalla into JDK-8372954
>>  - ... and 3 more: https://git.openjdk.org/valhalla/compare/e31f9f53...29344379
>
> src/hotspot/share/classfile/classFileParser.cpp line 1399:
> 
>> 1397:   // one for the field the JVM injects when detecting an empty inline class
>> 1398:   const int total_fields = length + num_injected + (is_inline_type ? 2 : 0)
>> 1399:                            + (is_value_class ? 1 : 0);
> 
> Can you update the comment block above to include something like:
> 
> // all value classes, even abstract ones, get an additional slot for the acmp_maps field used by the substitutability check
> 
> 
> We need something to make it clear why we're testing both inline type and value class here and what the new field is

Could you update the comment above, replacing the mention to the pre-allocated default value with the a mention to the null-reset value? 
This is not related to the removal of the old substitutability method, but it's an easy cleanup to do.
Thanks.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2012#discussion_r2759263758

From mcimadamore at openjdk.org  Tue Feb  3 14:16:16 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 14:16:16 GMT
Subject: RFR: [type-classes] Witness symbols with wrong owner lead to verifier
 errors
Message-ID: <cvlWi8ht5e9oOnpOJF6Qxk2AlD_vh-xY3hxNlQjewXg=.2bf720a1-bfcc-4620-998e-aa4a92450a52@github.com>

A witness lookup of the kind `T.__witness` is translated as a condy instruction.
Condy-backed `ldc` are modelled in the AST as references to `DynamicVariableSymbol`.
Such symbols have a owner. While the owner of a dynamic symbol is relatively unimportant for code generation issues (we don't need it to emit the correct bytecode), other compilation steps (such as `LambdaToMethod`) might be tricked into thinking that the dynamic symbol is actually a reference to an enclosing class symbol. This happens if the dynamic symbol owner is set to be a class symbol, instead of a method symbol.

The fix is therefore to translate the dynamic symbol of a witness lookup as a "local variable" -- that is, a variable symbol whose owner is a method (not a class) symbol.

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

Commit messages:
 - Initial push

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

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

From qamai at openjdk.org  Tue Feb  3 14:57:24 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 14:57:24 GMT
Subject: [lworld] RFR: 8376059: [lworld] Fix the issues in code generation
 of StoreLSpecialNode [v3]
In-Reply-To: <-AGw9FyRm61va62-PmJ_VOhkI9QJrxx-iCFJ8K45dCU=.4f2954f8-a75c-4989-9d7f-425cef2a3c20@github.com>
References: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
 <-AGw9FyRm61va62-PmJ_VOhkI9QJrxx-iCFJ8K45dCU=.4f2954f8-a75c-4989-9d7f-425cef2a3c20@github.com>
Message-ID: <1w78mc2V7APzaZ6ehLSfnqPeiKUprV0oh5yA8FejWtI=.d02b37a9-a1e5-4ce8-bdf2-787ef331ab35@github.com>

On Tue, 3 Feb 2026 12:57:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Many thanks to @stefank for finding the issue and helping investigating it. This PR fixes a couple of issues:
>> 
>> - On Aarch64, `g1StoreLSpecialOneOop` does not save `mem` and `src` during the GC pre-barrier, this risks clobber these values, which may lead to crashes or memory corruption when doing the store instruction.
>> - It seems that the value passed to the post-barrier should be an uncompressed oop, this requires us to decode the narrow oop instead of simply zero-extending it.
>> - Relax the restriction on the `src` register to be an arbitrary register.
>> - Split the rule into 2 so that we can avoid cloberring an additional register on Aarch64 when the offset of the oop inside the payload is 0, it also makes the implementation a little easier to read.
>> 
>> Testing:
>> - [x] tier1-4, valhalla-comp-stress, linux-aarch64
>> - [x] tier1-4, valhalla-comp-stress, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
>> - [x] tier1-4, valhalla-comp-stress, linux-x64
>> - [x] tier1-4, valhalla-comp-stress, linux-x64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix x64, add assert in StoreFlatNode::expand_atomic

Thanks a lot for your approval!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2013#issuecomment-3841817553

From qamai at openjdk.org  Tue Feb  3 14:57:26 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 14:57:26 GMT
Subject: [lworld] Integrated: 8376059: [lworld] Fix the issues in code
 generation of StoreLSpecialNode
In-Reply-To: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
References: <MUx4lI2oXKAQQ8zqf9UHJnkhOp_S_m-FEdL7_S1mXBA=.bd1f9c5a-8651-41d5-8342-d09a2fc7fdcb@github.com>
Message-ID: <4ffJpXi2uD7wIBUkq1T8czPaXpZVdA0TutYITkdgnsA=.e29eb872-41f5-47b2-9635-b04811b69bc4@github.com>

On Mon, 2 Feb 2026 15:43:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Many thanks to @stefank for finding the issue and helping investigating it. This PR fixes a couple of issues:
> 
> - On Aarch64, `g1StoreLSpecialOneOop` does not save `mem` and `src` during the GC pre-barrier, this risks clobber these values, which may lead to crashes or memory corruption when doing the store instruction.
> - It seems that the value passed to the post-barrier should be an uncompressed oop, this requires us to decode the narrow oop instead of simply zero-extending it.
> - Relax the restriction on the `src` register to be an arbitrary register.
> - Split the rule into 2 so that we can avoid cloberring an additional register on Aarch64 when the offset of the oop inside the payload is 0, it also makes the implementation a little easier to read.
> 
> Testing:
> - [x] tier1-4, valhalla-comp-stress, linux-aarch64
> - [x] tier1-4, valhalla-comp-stress, linux-aarch64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
> - [x] tier1-4, valhalla-comp-stress, linux-x64
> - [x] tier1-4, valhalla-comp-stress, linux-x64, with `-XX:+StressGCM -XX:InitiatingHeapOccupancyPercent=0 -Xmn10m`
> 
> Please take a look and leave your reviews, thanks a lot.

This pull request has now been integrated.

Changeset: 3407ba86
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3407ba86e52872e206d81fa24ebbfd3621a02f8d
Stats:     130 lines in 4 files changed: 86 ins; 13 del; 31 mod

8376059: [lworld] Fix the issues in code generation of StoreLSpecialNode

Reviewed-by: thartmann

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

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

From qamai at openjdk.org  Tue Feb  3 15:06:59 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 15:06:59 GMT
Subject: [lworld] RFR: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 [v2]
In-Reply-To: <8RHkOLZjKKCaB6-Tau6D8zgL40e2_TLoSCokFO9KMXI=.7514266f-50eb-4597-b0a4-109a921ca1b0@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
 <-AR1HlbCUWfj8uROJxtGCwjPn7iOIPl_AqAGoNkTQ58=.92b8386b-c5d7-416e-afc3-58f600eb855e@github.com>
 <8RHkOLZjKKCaB6-Tau6D8zgL40e2_TLoSCokFO9KMXI=.7514266f-50eb-4597-b0a4-109a921ca1b0@github.com>
Message-ID: <ddsU9jiyr8iLmq-b-H6BlJNU4i5SUP2CtQA7LaJSeF0=.50e42542-d445-4e28-aa06-4759d5502a55@github.com>

On Tue, 3 Feb 2026 11:28:12 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:
>> 
>>   Enable tests from 8325632
>
> Okay, sounds good. Maybe we should then just reduce the warmup iterations for those tests.

@TobiHartmann Thanks very much for your speedy reviews ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/2016#issuecomment-3841862324

From qamai at openjdk.org  Tue Feb  3 15:07:01 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 3 Feb 2026 15:07:01 GMT
Subject: [lworld] Integrated: 8376702: [lworld]
 MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
In-Reply-To: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
References: <NZVFZL1bjICnp3m05IQamD02DkXWqu7MwCEp7QD_Z7k=.bbd815bb-a028-4ab4-bbf0-2462978b217c@github.com>
Message-ID: <Cft1Rxz_6bqDWe9ZVLqDse0XaKB8C5zxXl2XFRNSO8c=.9d308939-9662-4b73-bd92-1b0a0c1c046c@github.com>

On Mon, 2 Feb 2026 17:52:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> I cannot manage to reproduce the issue, and it seems to fail only once in our CI. From the log, it seems that the issue is due to the fact that the pointer input to the `Load` is a `Proj` but its input dies, so the cast `as_Multi` in `try_optimize_strict_final_load_memory` fails. I can see a similar check in `MemNode::optimize_simple_memory_chain`. As a result, it is reasonable to just return the top here.
> 
> Please take a look and leave your review, thanks a lot.

This pull request has now been integrated.

Changeset: c09d99d2
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c09d99d2f3d9804eba0b712cfd3c457106f97882
Stats:     9 lines in 2 files changed: 3 ins; 3 del; 3 mod

8376702: [lworld] MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"

Reviewed-by: thartmann

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

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

From jlahoda at openjdk.org  Tue Feb  3 15:09:21 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Feb 2026 15:09:21 GMT
Subject: RFR: Show null restriction markers in javadoc.
Message-ID: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>

Adds null markers inside generated javadoc like this:
<img width="1144" height="528" alt="null-markers-javadoc" src="https://github.com/user-attachments/assets/b97736ff-f240-4c88-b874-32a8f7c8743c" />

Not sure if this is the ideal UI, and this is the best way to do implement it.

I didn't add tests yet, given the representation may change with experience.

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

Commit messages:
 - Show null restriction markers in javadoc.

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

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

From phubner at openjdk.org  Tue Feb  3 15:18:13 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 3 Feb 2026 15:18:13 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v4]
In-Reply-To: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
Message-ID: <e1FkhAUK3y1EMK28o6hsGmBZiVyAsQzedT4j0MF4Z-8=.d2fb1e93-c86f-4395-b15c-20d9a3d5fb68@github.com>

> Hi all,
> 
> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
> 
> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

Paul H?bner 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 15 additional commits since the last revision:

 - Comment enhancement
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
 - Missed obsolete test
 - Years
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
 - substitutability contract changed
 - Legacy handling in ProcessHandleImpl
 - typo
 - Test flags
 - ... and 5 more: https://git.openjdk.org/valhalla/compare/a98185f2...cdce2b10

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2012/files
  - new: https://git.openjdk.org/valhalla/pull/2012/files/29344379..cdce2b10

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

  Stats: 13437 lines in 379 files changed: 8384 ins; 1885 del; 3168 mod
  Patch: https://git.openjdk.org/valhalla/pull/2012.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2012/head:pull/2012

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

From liach at openjdk.org  Tue Feb  3 15:18:16 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Feb 2026 15:18:16 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <RDdI9sRucsKaQM3DZSDhZF2mWoZQKBrYI4Y2R_dsbsE=.7a13953b-8f07-4de5-850c-0c0bc8718403@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
 <QHHx6pKwlDcJRMCM0fVBBedNCQwgCEOZ5mAPyTv1iLg=.f10ef6ac-6f83-471d-86aa-d2fd1726ee6f@github.com>
 <RDdI9sRucsKaQM3DZSDhZF2mWoZQKBrYI4Y2R_dsbsE=.7a13953b-8f07-4de5-850c-0c0bc8718403@github.com>
Message-ID: <S3UCNywALf83oeyFIin3wdSCJPR0oxmmsErKbsy3mcE=.bf9e4e06-59fe-45e0-a7fa-525b6e4f33dc@github.com>

On Tue, 3 Feb 2026 14:05:43 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 1399:
>> 
>>> 1397:   // one for the field the JVM injects when detecting an empty inline class
>>> 1398:   const int total_fields = length + num_injected + (is_inline_type ? 2 : 0)
>>> 1399:                            + (is_value_class ? 1 : 0);
>> 
>> Can you update the comment block above to include something like:
>> 
>> // all value classes, even abstract ones, get an additional slot for the acmp_maps field used by the substitutability check
>> 
>> 
>> We need something to make it clear why we're testing both inline type and value class here and what the new field is
>
> Could you update the comment above, replacing the mention to the pre-allocated default value with the a mention to the null-reset value? 
> This is not related to the removal of the old substitutability method, but it's an easy cleanup to do.
> Thanks.

I have added the comments and briefly describes the field map records superclass fields so it is computed recursively and is present on AVCs.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2012#discussion_r2759587618

From fparain at openjdk.org  Tue Feb  3 15:22:46 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 3 Feb 2026 15:22:46 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <S3UCNywALf83oeyFIin3wdSCJPR0oxmmsErKbsy3mcE=.bf9e4e06-59fe-45e0-a7fa-525b6e4f33dc@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
 <QHHx6pKwlDcJRMCM0fVBBedNCQwgCEOZ5mAPyTv1iLg=.f10ef6ac-6f83-471d-86aa-d2fd1726ee6f@github.com>
 <RDdI9sRucsKaQM3DZSDhZF2mWoZQKBrYI4Y2R_dsbsE=.7a13953b-8f07-4de5-850c-0c0bc8718403@github.com>
 <S3UCNywALf83oeyFIin3wdSCJPR0oxmmsErKbsy3mcE=.bf9e4e06-59fe-45e0-a7fa-525b6e4f33dc@github.com>
Message-ID: <eloOl5W_rGXjGWTLngoAyqqjgJU5-Tz3llvTSmHrLnI=.407e23ae-30f0-4927-b3f0-ac67f3269ef7@github.com>

On Tue, 3 Feb 2026 15:13:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Could you update the comment above, replacing the mention to the pre-allocated default value with the a mention to the null-reset value? 
>> This is not related to the removal of the old substitutability method, but it's an easy cleanup to do.
>> Thanks.
>
> I have added the comments and briefly describes the field map records superclass fields so it is computed recursively and is present on AVCs.

There's still the comment about the pre-allocated default value, concept that doesn't exist anymore.
Instead, the slot is needed for the `.null_reset` static injected field, storing the value used to reset a nullable flat field when null is written to it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2012#discussion_r2759615093

From heidinga at openjdk.org  Tue Feb  3 15:37:08 2026
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 3 Feb 2026 15:37:08 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v4]
In-Reply-To: <e1FkhAUK3y1EMK28o6hsGmBZiVyAsQzedT4j0MF4Z-8=.d2fb1e93-c86f-4395-b15c-20d9a3d5fb68@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <e1FkhAUK3y1EMK28o6hsGmBZiVyAsQzedT4j0MF4Z-8=.d2fb1e93-c86f-4395-b15c-20d9a3d5fb68@github.com>
Message-ID: <Pq6tH1Fy1F53lYT5XqM-bxLwa8ukU-xZcgaXSPhri5k=.b49ea7c6-3f14-40da-8501-8b5f77b8ec61@github.com>

On Tue, 3 Feb 2026 15:18:13 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
>> 
>> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).
>
> Paul H?bner 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 15 additional commits since the last revision:
> 
>  - Comment enhancement
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>  - Missed obsolete test
>  - Years
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>  - substitutability contract changed
>  - Legacy handling in ProcessHandleImpl
>  - typo
>  - Test flags
>  - ... and 5 more: https://git.openjdk.org/valhalla/compare/e8715d92...cdce2b10

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

> 1396: 
> 1397:   // two more slots are required for inline classes:
> 1398:   //   - one for the static field with a reference to the pre-allocated default value

//   - one for the static .null_reset field used to reset a nullable field when null is written to it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2012#discussion_r2759680097

From mcimadamore at openjdk.org  Tue Feb  3 15:46:08 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 15:46:08 GMT
Subject: RFR: Show null restriction markers in javadoc.
In-Reply-To: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
References: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
Message-ID: <4mlx4ivSW-XpRPmNMr6IirW3U-hPxvM0l7n9dIFrcys=.2f1f6ede-c180-48e5-ba9a-0caa26d1f29b@github.com>

On Tue, 3 Feb 2026 15:03:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adds null markers inside generated javadoc like this:
> <img width="1144" height="528" alt="null-markers-javadoc" src="https://github.com/user-attachments/assets/b97736ff-f240-4c88-b874-32a8f7c8743c" />
> 
> Not sure if this is the ideal UI, and this is the best way to do implement it.
> 
> I didn't add tests yet, given the representation may change with experience.

Looks great! Much simpler than I though it would be.

We should probably add some kind of test?

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

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2022#pullrequestreview-3746018116
PR Comment: https://git.openjdk.org/valhalla/pull/2022#issuecomment-3842080528

From vromero at openjdk.org  Tue Feb  3 15:46:08 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 15:46:08 GMT
Subject: RFR: Show null restriction markers in javadoc.
In-Reply-To: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
References: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
Message-ID: <Dl4dNw90tWg580zwidUREwBlSwb7a4lZBzLAgzQAVgY=.68f8fbd6-73e4-4c2f-9c12-6aaa0f446b08@github.com>

On Tue, 3 Feb 2026 15:03:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adds null markers inside generated javadoc like this:
> <img width="1144" height="528" alt="null-markers-javadoc" src="https://github.com/user-attachments/assets/b97736ff-f240-4c88-b874-32a8f7c8743c" />
> 
> Not sure if this is the ideal UI, and this is the best way to do implement it.
> 
> I didn't add tests yet, given the representation may change with experience.

lgtm

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2022#pullrequestreview-3746025583

From thartmann at openjdk.org  Tue Feb  3 16:06:29 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Feb 2026 16:06:29 GMT
Subject: [lworld] Integrated: 8375547: [lworld] Dependency verification fails
 with assert "Should have been marked for deoptimization"
In-Reply-To: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
References: <cCoE5rnOf2ct2wsqx-l3LSHgSO0pwGZFz74-jdxnatk=.b1acf3c1-c413-45ab-a07a-fa24537838d9@github.com>
Message-ID: <OM4wngD4ykl0CDhboOiDyBv10JgWkHvK81HZxopAVGQ=.08b7ccf2-bbd9-4092-976e-2dad69fa6a3a@github.com>

On Mon, 2 Feb 2026 15:44:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When detecting a mismatch in the calling convention, we call `super_method->set_mismatch()` out of the scope of the `Compile_lock`. When class loading/linking happens in parallel, other dependencies might be invalidated and nmethods will be marked for deoptimization. Verification code will then check that all nmethods that have violated dependencies have been marked. The verification will fail once it finds a nmethod that now has a violated dependency not due to the class loading but due to the mismatch that we just set.
> 
> Similar to how the [runtime handles similar situations](https://github.com/openjdk/valhalla/blob/2ad3ce1646bb5c717239f683686dd1034a9340c1/src/hotspot/share/oops/instanceKlass.cpp#L1230-L1235), `set_mismatch` needs to be performed while holding the lock. We then keep the lock until we marked all methods.
> 
> When looking at the code, I noticed that more instructions can be moved out of the scope of the lock, so I did that as well.
> 
> I quickly looked into creating a regression test for this but it's non-trivial. Also, our internal testing triggers this reliably, so I decided to go without a regression test for now.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 750a2f99
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/750a2f997b42cb96205d82ccfb7a81a20a2cf014
Stats:     10 lines in 1 file changed: 6 ins; 2 del; 2 mod

8375547: [lworld] Dependency verification fails with assert "Should have been marked for deoptimization"

Reviewed-by: mchevalier

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

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

From phubner at openjdk.org  Tue Feb  3 16:13:22 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 3 Feb 2026 16:13:22 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v5]
In-Reply-To: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
Message-ID: <GYZ0NjrPAtow6qX7TMY-GoiAQJz0vTeRVUUGrslI174=.a1509259-d47c-4003-8e5c-385555f2cdd2@github.com>

> Hi all,
> 
> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
> 
> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

Paul H?bner has updated the pull request incrementally with two additional commits since the last revision:

 - Silly typo
 - Improve comment, refer to where they are injected

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2012/files
  - new: https://git.openjdk.org/valhalla/pull/2012/files/cdce2b10..1b17a2f2

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

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

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

From liach at openjdk.org  Tue Feb  3 16:13:25 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Feb 2026 16:13:25 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <eloOl5W_rGXjGWTLngoAyqqjgJU5-Tz3llvTSmHrLnI=.407e23ae-30f0-4927-b3f0-ac67f3269ef7@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
 <QHHx6pKwlDcJRMCM0fVBBedNCQwgCEOZ5mAPyTv1iLg=.f10ef6ac-6f83-471d-86aa-d2fd1726ee6f@github.com>
 <RDdI9sRucsKaQM3DZSDhZF2mWoZQKBrYI4Y2R_dsbsE=.7a13953b-8f07-4de5-850c-0c0bc8718403@github.com>
 <S3UCNywALf83oeyFIin3wdSCJPR0oxmmsErKbsy3mcE=.bf9e4e06-59fe-45e0-a7fa-525b6e4f33dc@github.com>
 <eloOl5W_rGXjGWTLngoAyqqjgJU5-Tz3llvTSmHrLnI=.407e23ae-30f0-4927-b3f0-ac67f3269ef7@github.com>
Message-ID: <MCTRkmMAmdR7SIwVbCQ95KFGFrtyM_eUhwxpNSvDp2A=.03c4a33c-1ba9-4361-8959-53f56a7398aa@github.com>

On Tue, 3 Feb 2026 15:19:49 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> I have added the comments and briefly describes the field map records superclass fields so it is computed recursively and is present on AVCs.
>
> There's still the comment about the pre-allocated default value, concept that doesn't exist anymore.
> Instead, the slot is needed for the `.null_reset` static injected field, storing the value used to reset a nullable flat field when null is written to it.

Sure. I have revised the comments again, so this time we refer to their names and where they are added, so interested users can navigate on their own.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2012#discussion_r2759839946

From liach at openjdk.org  Tue Feb  3 16:23:46 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Feb 2026 16:23:46 GMT
Subject: RFR: Show null restriction markers in javadoc.
In-Reply-To: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
References: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
Message-ID: <DOfg8gTxDCkXkSpfiubhD7I4C6R1tw7deliqUdZod2k=.fd8fa737-46fe-4989-8029-e7993e2f0c47@github.com>

On Tue, 3 Feb 2026 15:03:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adds null markers inside generated javadoc like this:
> <img width="1144" height="528" alt="null-markers-javadoc" src="https://github.com/user-attachments/assets/b97736ff-f240-4c88-b874-32a8f7c8743c" />
> 
> Not sure if this is the ideal UI, and this is the best way to do implement it.
> 
> I didn't add tests yet, given the representation may change with experience.

This is ok for now, we can patch Utils.getTypeSignature if we find that one need updates too. (Just curious, do method signatures print correctly now)

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2022#pullrequestreview-3746233155

From mcimadamore at openjdk.org  Tue Feb  3 17:00:59 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 17:00:59 GMT
Subject: Integrated: [type-classes] Witness symbols with wrong owner lead to
 verifier errors
In-Reply-To: <cvlWi8ht5e9oOnpOJF6Qxk2AlD_vh-xY3hxNlQjewXg=.2bf720a1-bfcc-4620-998e-aa4a92450a52@github.com>
References: <cvlWi8ht5e9oOnpOJF6Qxk2AlD_vh-xY3hxNlQjewXg=.2bf720a1-bfcc-4620-998e-aa4a92450a52@github.com>
Message-ID: <2mkKzcA0AfG3cOLEiqNycYg5exA0sUdDd_82QtZsgpk=.f2d2acd1-8eca-4b7b-b30f-5763516e1ae9@github.com>

On Tue, 3 Feb 2026 14:10:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> A witness lookup of the kind `T.__witness` is translated as a condy instruction.
> Condy-backed `ldc` are modelled in the AST as references to `DynamicVariableSymbol`.
> Such symbols have a owner. While the owner of a dynamic symbol is relatively unimportant for code generation issues (we don't need it to emit the correct bytecode), other compilation steps (such as `LambdaToMethod`) might be tricked into thinking that the dynamic symbol is actually a reference to an enclosing class symbol. This happens if the dynamic symbol owner is set to be a class symbol, instead of a method symbol.
> 
> The fix is therefore to translate the dynamic symbol of a witness lookup as a "local variable" -- that is, a variable symbol whose owner is a method (not a class) symbol.

This pull request has now been integrated.

Changeset: ffef89ab
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ffef89aba3f213733859b76ad2facd878c680c6e
Stats:     70 lines in 2 files changed: 69 ins; 0 del; 1 mod

[type-classes] Witness symbols with wrong owner lead to verifier errors

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

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

From fparain at openjdk.org  Tue Feb  3 17:52:23 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 3 Feb 2026 17:52:23 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v5]
In-Reply-To: <GYZ0NjrPAtow6qX7TMY-GoiAQJz0vTeRVUUGrslI174=.a1509259-d47c-4003-8e5c-385555f2cdd2@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <GYZ0NjrPAtow6qX7TMY-GoiAQJz0vTeRVUUGrslI174=.a1509259-d47c-4003-8e5c-385555f2cdd2@github.com>
Message-ID: <aPAfm-AZIhb-g6KGLY4zzqcsiD80N7cmnhJLVPEsHDU=.6b864088-7d70-4295-a332-5c34f14e9f82@github.com>

On Tue, 3 Feb 2026 16:13:22 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
>> 
>> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).
>
> Paul H?bner has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Silly typo
>  - Improve comment, refer to where they are injected

Looks good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2012#pullrequestreview-3746691632

From fparain at openjdk.org  Tue Feb  3 17:52:24 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 3 Feb 2026 17:52:24 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <MCTRkmMAmdR7SIwVbCQ95KFGFrtyM_eUhwxpNSvDp2A=.03c4a33c-1ba9-4361-8959-53f56a7398aa@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <sXLf8A_Hfz-GRmhR-BI3NpN4zEnOyYTjqUf0l_PbXXI=.6c6be175-38ca-400f-a96d-ba089f9d96d8@github.com>
 <QHHx6pKwlDcJRMCM0fVBBedNCQwgCEOZ5mAPyTv1iLg=.f10ef6ac-6f83-471d-86aa-d2fd1726ee6f@github.com>
 <RDdI9sRucsKaQM3DZSDhZF2mWoZQKBrYI4Y2R_dsbsE=.7a13953b-8f07-4de5-850c-0c0bc8718403@github.com>
 <S3UCNywALf83oeyFIin3wdSCJPR0oxmmsErKbsy3mcE=.bf9e4e06-59fe-45e0-a7fa-525b6e4f33dc@github.com>
 <eloOl5W_rGXjGWTLngoAyqqjgJU5-Tz3llvTSmHrLnI=.407e23ae-30f0-4927-b3f0-ac67f3269ef7@github.com>
 <MCTRkmMAmdR7SIwVbCQ95KFGFrtyM_eUhwxpNSvDp2A=.03c4a33c-1ba9-4361-8959-53f56a7398aa@github.com>
Message-ID: <yWfpJvlq5HGSsiLjoAEdvxYwU41zFZGwE_h9urCMPjA=.13d57a0c-85c4-4989-b1b4-9539e535c49a@github.com>

On Tue, 3 Feb 2026 16:06:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> There's still the comment about the pre-allocated default value, concept that doesn't exist anymore.
>> Instead, the slot is needed for the `.null_reset` static injected field, storing the value used to reset a nullable flat field when null is written to it.
>
> Sure. I have revised the comments again, so this time we refer to their names and where they are added, so interested users can navigate on their own.

Thank you for the updated comment.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2012#discussion_r2760272852

From darcy at openjdk.org  Tue Feb  3 18:03:58 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Feb 2026 18:03:58 GMT
Subject: RFR: [type-classes] 8377095: Update basic tests for UnsignedInt to use
 lambdas
Message-ID: <dSb4tt8PpENSdb13tgCWNiz8P4HgaBzo7SO-Am8-Q3E=.1bf8909b-ecfc-4420-b71d-b8e1b1fd6ddf@github.com>

With a recent javac code generation fix, update the UnsignedInt class to use lambdas.

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

Commit messages:
 - 8377095: Update basic tests for UnsignedInt to use lambdas

Changes: https://git.openjdk.org/valhalla/pull/2024/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2024&range=00
  Stats: 27 lines in 2 files changed: 3 ins; 21 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/2024.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2024/head:pull/2024

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

From liach at openjdk.org  Tue Feb  3 18:03:59 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Feb 2026 18:03:59 GMT
Subject: RFR: [type-classes] 8377095: Update basic tests for UnsignedInt to
 use lambdas
In-Reply-To: <dSb4tt8PpENSdb13tgCWNiz8P4HgaBzo7SO-Am8-Q3E=.1bf8909b-ecfc-4420-b71d-b8e1b1fd6ddf@github.com>
References: <dSb4tt8PpENSdb13tgCWNiz8P4HgaBzo7SO-Am8-Q3E=.1bf8909b-ecfc-4420-b71d-b8e1b1fd6ddf@github.com>
Message-ID: <EZC72P8P23qyIl0oGmB-9lik83Hw6sQZr4pzWtOS4dQ=.96348d83-38ef-43a5-b754-d9bd3bb32695@github.com>

On Tue, 3 Feb 2026 17:42:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With a recent javac code generation fix, update the UnsignedInt class to use lambdas.

Simple and clean fix.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2024#pullrequestreview-3746736559

From darcy at openjdk.org  Tue Feb  3 18:04:01 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Feb 2026 18:04:01 GMT
Subject: RFR: [type-classes] 8377095: Update basic tests for UnsignedInt to
 use lambdas
In-Reply-To: <dSb4tt8PpENSdb13tgCWNiz8P4HgaBzo7SO-Am8-Q3E=.1bf8909b-ecfc-4420-b71d-b8e1b1fd6ddf@github.com>
References: <dSb4tt8PpENSdb13tgCWNiz8P4HgaBzo7SO-Am8-Q3E=.1bf8909b-ecfc-4420-b71d-b8e1b1fd6ddf@github.com>
Message-ID: <HxGgq9N4GHwyntgZvkjtYVpDfdAoFuRwJKusWIL2_PY=.0958d093-005d-45bf-8ed8-0098245bc6e3@github.com>

On Tue, 3 Feb 2026 17:42:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With a recent javac code generation fix, update the UnsignedInt class to use lambdas.

src/java.base/share/classes/java/lang/UnsignedInt.java line 41:

> 39:     // implementing Serializable. Might implement Comparable<UnsignedInt>.
> 40: 
> 41:     private static final Integral<UnsignedInt> INT = new Integral<UnsignedInt>() {

FYI, implementing a previously discussed change: https://github.com/openjdk/valhalla/pull/1991/changes#r2743332791

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2024#discussion_r2760292267

From phubner at openjdk.org  Tue Feb  3 18:18:59 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 3 Feb 2026 18:18:59 GMT
Subject: [lworld] RFR: 8372954: [lworld] Remove old implementation of the
 substitutability test method [v3]
In-Reply-To: <7l7hTZg6rrGWe4LOXOlJ2c-6GuBTHvpv8qbVGuwhXTg=.2a3cf79d-3337-404b-b4aa-3a444337fd43@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
 <XZD_9PsAEASD0FzCJCdWpjaZmlk_2p6NTwJXYo4YjYk=.8808126d-a583-490b-abd7-55da687e344c@github.com>
 <7l7hTZg6rrGWe4LOXOlJ2c-6GuBTHvpv8qbVGuwhXTg=.2a3cf79d-3337-404b-b4aa-3a444337fd43@github.com>
Message-ID: <_r67hSt-csgeJEEeofO3p2v7M_2ys6tRHKeEtW34QqA=.24ee4af3-b619-4928-b8c6-66309955588c@github.com>

On Mon, 2 Feb 2026 18:38:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Paul H?bner 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 13 additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>>  - Missed obsolete test
>>  - Years
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into JDK-8372954
>>  - substitutability contract changed
>>  - Legacy handling in ProcessHandleImpl
>>  - typo
>>  - Test flags
>>  - Dead stuff
>>  - Merge branch 'JDK-8372954' of github.com:Arraying/valhalla into JDK-8372954
>>  - ... and 3 more: https://git.openjdk.org/valhalla/compare/38ee0d18...29344379
>
> The java file changes look fine.

Thanks for the reviews @RogerRiggs @TobiHartmann @DanHeidinga @fparain. Also a big thank you to @liach for doing the bulk of the work and handling reviewer feedback.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2012#issuecomment-3842890935

From phubner at openjdk.org  Tue Feb  3 18:22:01 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 3 Feb 2026 18:22:01 GMT
Subject: [lworld] Integrated: 8372954: [lworld] Remove old implementation of
 the substitutability test method
In-Reply-To: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
References: <miI9Ad5NV-x3-UVnRlCHrKNszOXflZb3PjHts3cso-E=.9370dede-4e90-4ea9-b196-9c89be02900a@github.com>
Message-ID: <ebEdaRIxSVvB2QgQr-T2Qi4vWFLs8j_atk8KF-pPs9o=.e492abd1-a1ed-459d-be47-2dd574415636@github.com>

On Mon, 2 Feb 2026 15:38:24 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This change removes the old substitutability test method. The new/alt substitutability test takes the place of the legacy test, and all identifiers with "alt" are removed.
> 
> Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

This pull request has now been integrated.

Changeset: 2b06c93b
Author:    Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2b06c93b0122d749579c89b0b55a32c49e0e0754
Stats:     1927 lines in 26 files changed: 11 ins; 1862 del; 54 mod

8372954: [lworld] Remove old implementation of the substitutability test method

Co-authored-by: Chen Liang <liach at openjdk.org>
Reviewed-by: rriggs, thartmann, fparain

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

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

From darcy at openjdk.org  Tue Feb  3 18:23:54 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Feb 2026 18:23:54 GMT
Subject: Integrated: [type-classes] 8377095: Update basic tests for UnsignedInt
 to use lambdas
In-Reply-To: <dSb4tt8PpENSdb13tgCWNiz8P4HgaBzo7SO-Am8-Q3E=.1bf8909b-ecfc-4420-b71d-b8e1b1fd6ddf@github.com>
References: <dSb4tt8PpENSdb13tgCWNiz8P4HgaBzo7SO-Am8-Q3E=.1bf8909b-ecfc-4420-b71d-b8e1b1fd6ddf@github.com>
Message-ID: <JLEMfpK7QNNpwvCXFiGmlq1H6D6uhTQ9jlO6sAUdOtA=.03f59624-4e57-42e3-be2a-bab611b825e0@github.com>

On Tue, 3 Feb 2026 17:42:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With a recent javac code generation fix, update the UnsignedInt class to use lambdas.

This pull request has now been integrated.

Changeset: 81a9db9c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/81a9db9c1cabe2bb9d339920b2b65fbfb60728c9
Stats:     27 lines in 2 files changed: 3 ins; 21 del; 3 mod

[type-classes] 8377095: Update basic tests for UnsignedInt to use lambdas

Reviewed-by: liach

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

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

From mcimadamore at openjdk.org  Tue Feb  3 18:32:54 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 18:32:54 GMT
Subject: [lworld] RFR: 8373916: [lworld] TypeName.this.FieldName should be
 restricted in early construction context [v2]
In-Reply-To: <rEBhaTceHdd-z8YdFJ6-Vvse83y-0oPbe5ueNMERgKY=.65f34f31-20aa-4eef-9763-0635d0469cf3@github.com>
References: <PFIV5VMh3yr89nSroOnlExmiW_vaEtGooltfIXeUMJM=.9b82025e-99ec-430a-b40d-f2681d9a6437@github.com>
 <rEBhaTceHdd-z8YdFJ6-Vvse83y-0oPbe5ueNMERgKY=.65f34f31-20aa-4eef-9763-0635d0469cf3@github.com>
Message-ID: <YAHcwb3fH5lq04HyJNCSvyikXq4ln6AYNuXCAyhoTEE=.dc0fd584-ff82-4a28-bd3f-5eae478b2b31@github.com>

On Fri, 23 Jan 2026 15:30:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> According to spec bugs: JDK-8373719 and JDK-8373721:
>> 
>> In JLS 6.5.6.1, references to fields are subject to a handful of restrictions if they refer to instance fields. In 15.8 and 15.11, 'this.x' and 'super.x' are intended to be viewed as instance field references, and subject to the same restrictions.
>> 
>> So the following code should fail to compile:
>> 
>> class Test {
>>     static final boolean check = true;
>>     Test(int a) {
>>         boolean b = Test.this.check; //compilation error expected here
>>         this();
>>     }
>> }
>> 
>> However, javac is currently accepting it
>
> Vicente Romero 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:
> 
>  - adding test case
>  - Merge branch 'lworld' into JDK-8373916
>  - 8373916: [lworld] TypeName.this.FieldName should be restricted in early construction context

Looks good

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

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1899#pullrequestreview-3746890710

From vromero at openjdk.org  Tue Feb  3 19:48:13 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 19:48:13 GMT
Subject: RFR: Remove redundant null checks [v11]
In-Reply-To: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
References: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
Message-ID: <ne8ELMCzlsE7ZqzfWoHDOO-v3_z5FEf4p86fPnNjHIw=.a92361ee-59cf-4c9c-818c-31763628cc12@github.com>

> some of the null checks javac generates are redundant and can be removed

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  improving tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1947/files
  - new: https://git.openjdk.org/valhalla/pull/1947/files/69e7b3ac..7100d19f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=10
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=09-10

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

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

From vromero at openjdk.org  Tue Feb  3 20:21:58 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 20:21:58 GMT
Subject: Integrated: Remove redundant null checks
In-Reply-To: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
References: <kx0HPiG7MRt23Jv_BzohGD0KPpw_p4pYnpRTxP4KiYs=.27116a96-c3e1-4ef2-a96c-27d19110495e@github.com>
Message-ID: <YdZWkNWxup1pHWrSF8bjESRNgLbxPozeTJLAikhNRBw=.b97e0f33-3bcc-4799-b5f8-0ee02d61e735@github.com>

On Thu, 22 Jan 2026 17:03:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> some of the null checks javac generates are redundant and can be removed

This pull request has now been integrated.

Changeset: f384d1dd
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f384d1dd1844a893c81d8772037cd4b3fcf8a157
Stats:     341 lines in 4 files changed: 284 ins; 11 del; 46 mod

Remove redundant null checks

Reviewed-by: mcimadamore

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

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

From vromero at openjdk.org  Tue Feb  3 21:34:05 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 21:34:05 GMT
Subject: Integrated: Merge lworld
Message-ID: <5QcLUvnoBOklp_zmq38Hfo_aXitwMzKYSKLKYJaMIwc=.8e12783c-4b06-4dfa-8f48-59582ebfcb2e@github.com>

Merge branch 'lworld' into bworld_merge_lworld
# Conflicts:
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
#	test/jdk/valhalla/valuetypes/LayoutIterationTest.java

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

Commit messages:
 - Merge branch 'lworld' into bworld_merge_lworld
 - 8372954: [lworld] Remove old implementation of the substitutability test method
 - 8375547: [lworld] Dependency verification fails with assert "Should have been marked for deoptimization"
 - 8376702: [lworld] MemNode::optimize_simple_memory_chain asserts with "invalid node class: Con"
 - 8376059: [lworld] Fix the issues in code generation of StoreLSpecialNode
 - 8376221: [lworld] Do not store array of InlineLayoutInfo for all InstanceKlasses
 - Merge
 - 8375458: Check legal folder of JDK image for unwanted files
 - 8375978: G1: Convert G1Policy to use Atomic<T>
 - 8375977: G1: Convert JVMCICleaningTask to use Atomic<T>
 - ... and 96 more: https://git.openjdk.org/valhalla/compare/f384d1dd...21cb7beb

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

Changes: https://git.openjdk.org/valhalla/pull/2027/files
  Stats: 16334 lines in 429 files changed: 9194 ins; 3825 del; 3315 mod
  Patch: https://git.openjdk.org/valhalla/pull/2027.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2027/head:pull/2027

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

From vromero at openjdk.org  Tue Feb  3 21:34:06 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 21:34:06 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <5QcLUvnoBOklp_zmq38Hfo_aXitwMzKYSKLKYJaMIwc=.8e12783c-4b06-4dfa-8f48-59582ebfcb2e@github.com>
References: <5QcLUvnoBOklp_zmq38Hfo_aXitwMzKYSKLKYJaMIwc=.8e12783c-4b06-4dfa-8f48-59582ebfcb2e@github.com>
Message-ID: <8TogBDvIfUkrdOeoDMN7ygjhcKsgS9xrMYyy61hjFAc=.2a667222-654e-4048-ac42-10b031706104@github.com>

On Tue, 3 Feb 2026 21:27:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into bworld_merge_lworld
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
> #	test/jdk/valhalla/valuetypes/LayoutIterationTest.java

This pull request has now been integrated.

Changeset: 5a65b810
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5a65b8109275c35d7b0992e4c8f104bc155e62a0
Stats:     16334 lines in 429 files changed: 9194 ins; 3825 del; 3315 mod

Merge lworld

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

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

From matsaave at openjdk.org  Tue Feb  3 22:15:17 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 3 Feb 2026 22:15:17 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM according
 to strict fields JEP
Message-ID: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>

Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.

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

Commit messages:
 - Created different methods for strict_init
 - Merge branch 'lworld' into rename_acc_strict_8367935
 - 8367935: Rename ACC_STRICT in the JVM according to strict fields JEP

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

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

From liach at openjdk.org  Tue Feb  3 23:05:58 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Feb 2026 23:05:58 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP
In-Reply-To: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
Message-ID: <yLsnGTfdS8WipIcNEzG5ZqI8qQUCC-Se4kuQcx-dAAs=.e2f4a980-7d2a-49ee-a0f2-21eea8027326@github.com>

On Tue, 3 Feb 2026 20:21:48 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.

src/java.base/share/classes/java/lang/invoke/MemberName.java line 398:

> 396:      /** Utility method to query the modifier flags of this member. */
> 397:     public boolean isStrictInit() {
> 398:         return Modifier.isStrictInit(flags);

Let's do `allFlagsSet(ClassFile.ACC_STRICT_INIT);` and remove the stuff from `Modifier`. The `ACC_STRICT_INIT` flag is NOT a source modifier.

src/java.base/share/classes/java/lang/reflect/Modifier.java line 1:

> 1: /*

Please drop all changes to this file.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2025#discussion_r2761402633
PR Review Comment: https://git.openjdk.org/valhalla/pull/2025#discussion_r2761403931

From rriggs at openjdk.org  Tue Feb  3 23:06:00 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 3 Feb 2026 23:06:00 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP
In-Reply-To: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
Message-ID: <wseDvD1oUJPp-CjW0F_wSJgPy7rawBJXkxPWjMNm26s=.565169af-36d6-4493-b487-4dcc689e5cf1@github.com>

On Tue, 3 Feb 2026 20:21:48 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.

src/java.base/share/classes/java/lang/reflect/Modifier.java line 220:

> 218:      * {@code strict_init} modifier; {@code false} otherwise.
> 219:      */
> 220:     public static boolean isStrictInit(int mod) {

Is a Modifier method really appropriate or needed?
Modifier is used to describe modifiers in the source and there is no language keyword for "strict init".
It is already defined in AccessFlag and that should be sufficient for the use cases.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2025#discussion_r2761399646

From darcy at openjdk.org  Tue Feb  3 23:29:49 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Feb 2026 23:29:49 GMT
Subject: RFR: [type-classes] 8377123: Add SIZE and BYTES static fields to
 UnsignedInt
Message-ID: <Y3wToYG3mIX6NdR1OHCFNMcJ4p8PFd9xRNz8mnfyrWM=.4ee23942-8572-44d0-99c7-8fd04e0d5e20@github.com>

Add SIZE and BYTES fields to UnsignedInt, analagous to those fields from java.lang.Integer.

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

Commit messages:
 - 8377123: Add SIZE and BYTES static fields to UnsignedInt

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

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

From jsikstro at openjdk.org  Wed Feb  4 08:08:27 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 4 Feb 2026 08:08:27 GMT
Subject: [lworld] RFR: 8376813: [lworld] Add print for dummy field reused
 as null-marker [v2]
In-Reply-To: <nEB3XhTr392Dd0ptl9XZKdokgf5sSUIffuCAPLTgyzs=.5c52d1d3-7121-424b-b458-6dabf42178f4@github.com>
References: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
 <iCO233rLVT6BsjL_4fomeXfZqse7z2jg0yZJ8sQmRkg=.1bf1cbf4-14c3-4188-b07d-b8507d61809d@github.com>
 <nEB3XhTr392Dd0ptl9XZKdokgf5sSUIffuCAPLTgyzs=.5c52d1d3-7121-424b-b458-6dabf42178f4@github.com>
Message-ID: <NL9sA9Jfw4jlfjR0xQQcv2NW-LhBWvraYdpZKadBajM=.d0626500-e5d9-4ef3-b571-28a1b77e30df@github.com>

On Mon, 2 Feb 2026 10:55:14 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Thanks for the changes, this makes debugging and developing a lot easier. One thing that came to mind is that we have a bunch of flat array specific printing logic in e.g. `FlatArrayKlass::oop_print_value_on`. As a possible extension, would we ever want to convey such information in the array itself, rather than the field? For example when debug-printing the human-version of the array header to indicate the null marker is reused as the dummy field (when applicable)?

I'm not entirely sure of how arrays work so I'd need to spend some time on figuring that out before giving a better answer. When trying to understand emtpy InlineKlasses, it wasn't immediately clear to me that the empty dummy-field was reused as the null-marker, so I'd say anything we can do to convey that more clearly is something we'd want to do.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2001#issuecomment-3845927992

From jsikstro at openjdk.org  Wed Feb  4 08:08:29 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 4 Feb 2026 08:08:29 GMT
Subject: [lworld] RFR: 8376813: [lworld] Add print for dummy field reused
 as null-marker [v2]
In-Reply-To: <iCO233rLVT6BsjL_4fomeXfZqse7z2jg0yZJ8sQmRkg=.1bf1cbf4-14c3-4188-b07d-b8507d61809d@github.com>
References: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
 <iCO233rLVT6BsjL_4fomeXfZqse7z2jg0yZJ8sQmRkg=.1bf1cbf4-14c3-4188-b07d-b8507d61809d@github.com>
Message-ID: <dRspO2-0zWGwvCEkYvX4Dy8T9_eIvDw9tREu77R48sw=.2f4cb3c5-25b9-4f75-a916-2108754eb9ed@github.com>

On Mon, 2 Feb 2026 09:27:33 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Right now it's not clear that the dummy field that is injected into empty inline klasses can be/is reused for the null-marker when looking at the printed layout from -XX:+PrintInlineLayout. I suggest we enhance this print to indicate if the dummy field has been reused for the null-marker.
>> 
>> I've tested that the added comment in the print is there when nullability is turned on (default), and not there when turned off (`-XX:-UseNullableValueFlattening -XX:-UseNullableNonAtomicValueFlattening`).
>> 
>> 
>> Before:
>> Instance fields:
>>  @0 RESERVED 12/-
>>  @12 REGULAR 1/1 ".empty" B
>> 
>> After:
>> Instance fields:
>>  @0 RESERVED 12/-
>>  @12 REGULAR 1/1 ".empty" B (reused as null-marker)
>> 
>> 
>> Testing:
>> * GHA
>> * Oracle's tier1
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no dummy field in static layout printing

Thank you for the reviews everyone! I reran tier1-2 on the tip of lworld, which is green.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2001#issuecomment-3845930895

From duke at openjdk.org  Wed Feb  4 08:11:49 2026
From: duke at openjdk.org (duke)
Date: Wed, 4 Feb 2026 08:11:49 GMT
Subject: [lworld] RFR: 8376813: [lworld] Add print for dummy field reused
 as null-marker [v2]
In-Reply-To: <iCO233rLVT6BsjL_4fomeXfZqse7z2jg0yZJ8sQmRkg=.1bf1cbf4-14c3-4188-b07d-b8507d61809d@github.com>
References: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
 <iCO233rLVT6BsjL_4fomeXfZqse7z2jg0yZJ8sQmRkg=.1bf1cbf4-14c3-4188-b07d-b8507d61809d@github.com>
Message-ID: <NpxXEcKtd-8H-1EU3regYfGbsd53sq12j8vb6McndkY=.d3f0cb1e-6680-4d47-8f27-161080d2f3b5@github.com>

On Mon, 2 Feb 2026 09:27:33 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Right now it's not clear that the dummy field that is injected into empty inline klasses can be/is reused for the null-marker when looking at the printed layout from -XX:+PrintInlineLayout. I suggest we enhance this print to indicate if the dummy field has been reused for the null-marker.
>> 
>> I've tested that the added comment in the print is there when nullability is turned on (default), and not there when turned off (`-XX:-UseNullableValueFlattening -XX:-UseNullableNonAtomicValueFlattening`).
>> 
>> 
>> Before:
>> Instance fields:
>>  @0 RESERVED 12/-
>>  @12 REGULAR 1/1 ".empty" B
>> 
>> After:
>> Instance fields:
>>  @0 RESERVED 12/-
>>  @12 REGULAR 1/1 ".empty" B (reused as null-marker)
>> 
>> 
>> Testing:
>> * GHA
>> * Oracle's tier1
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no dummy field in static layout printing

@jsikstro 
Your change (at version 87849f24d507c2cb52fe30bbc357d47b3fb115ac) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2001#issuecomment-3845941963

From jsikstro at openjdk.org  Wed Feb  4 08:17:28 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 4 Feb 2026 08:17:28 GMT
Subject: [lworld] Integrated: 8376813: [lworld] Add print for dummy field
 reused as null-marker
In-Reply-To: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
References: <vnclJK-fB0aDAe1sCL6KHm4vCBcxrmMUOU0WXY6mKhg=.9c0ae655-d036-4ee9-9289-64ccff31db8d@github.com>
Message-ID: <84GIYQ-98oj6pLzsqeqvHSrEsOTqvCpYBqYoF0YheKU=.cd0ee3f5-f28f-4913-b734-1f17bfee1cf6@github.com>

On Fri, 30 Jan 2026 15:29:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> Right now it's not clear that the dummy field that is injected into empty inline klasses can be/is reused for the null-marker when looking at the printed layout from -XX:+PrintInlineLayout. I suggest we enhance this print to indicate if the dummy field has been reused for the null-marker.
> 
> I've tested that the added comment in the print is there when nullability is turned on (default), and not there when turned off (`-XX:-UseNullableValueFlattening -XX:-UseNullableNonAtomicValueFlattening`).
> 
> 
> Before:
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 ".empty" B
> 
> After:
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 ".empty" B (reused as null-marker)
> 
> 
> Testing:
> * GHA
> * Oracle's tier1

This pull request has now been integrated.

Changeset: ff2e2092
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
Committer: Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ff2e20922e3c9ca2a206156cdb515dac1adce68c
Stats:     21 lines in 2 files changed: 10 ins; 0 del; 11 mod

8376813: [lworld] Add print for dummy field reused as null-marker

Reviewed-by: fparain, phubner

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

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

From phubner at openjdk.org  Wed Feb  4 09:11:10 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 4 Feb 2026 09:11:10 GMT
Subject: [lworld] RFR: 8376652: [lworld] Explicit and consistent names for
 nonstatic fields in FieldLayout [v4]
In-Reply-To: <dK3puls0Ta9D5OVMU-RdcDxSYFCJm7fIUvlH7tA2kD4=.caa3b0d7-d6e9-43ce-9669-78500fc2c89d@github.com>
References: <jdG9_wKNaRaGyN0kgk7oUt3gN0LhOMXziM-qu9b_l5k=.23998916-c182-46e7-bfab-cc91ea8cbc1b@github.com>
 <dK3puls0Ta9D5OVMU-RdcDxSYFCJm7fIUvlH7tA2kD4=.caa3b0d7-d6e9-43ce-9669-78500fc2c89d@github.com>
Message-ID: <STOlfL4TAiE88YMJ_IOJmO2uUOyVJElR3X_0s6yLWXM=.e7730285-f891-4ad5-9e9d-105895e94af5@github.com>

On Fri, 30 Jan 2026 08:23:13 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We should be explicit when naming variables that refer to "fields" and state whether we mean static or nonstatic fields.
>> 
>> I've also done a bit of cleanup in `FieldLayoutBuilder::compute_inline_class_layout()`, which calls `has_nonstatic_fields`. The "has_nonstatic_fields" property is inherited from the superklass whenever a klass instance is created, so we only have to check the property once on the "first" superklass.
>> 
>> Testing:
>> * Oracle's tier1-3, jdk_valhalla and hotspot_valhalla
>> * I added an assert to sanity test that the while loop I removed in `FieldLayoutBuilder::compute_inline_class_layout()` never gets past the "first" superklass, which didn't hit in tier1-3.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed closest_non_static to closest_nonstatic

Looks good to me, thanks for the cleanup.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1992#pullrequestreview-3749852211

From shade at openjdk.org  Wed Feb  4 09:16:46 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Feb 2026 09:16:46 GMT
Subject: [lworld] RFR: 8376103: [lworld] Basic Zero support [v3]
In-Reply-To: <cMhg_6DEG3p6LtO-M2KaX7X-o8BVvmccLZ13evyTXF8=.7257fd42-4474-41d5-855f-28d203aed19c@github.com>
References: <cMhg_6DEG3p6LtO-M2KaX7X-o8BVvmccLZ13evyTXF8=.7257fd42-4474-41d5-855f-28d203aed19c@github.com>
Message-ID: <4qp3Dh1-SmlwCaXvUI61EI5ahRa_tlg5RHR_kGBi--E=.e5977a1b-0988-425f-9976-0832c3e9d8ec@github.com>

> On the way to stabilizing Valhalla for inclusion into mainline, we want to have Zero builds at least buildable and lightly runnable, e.g. for creating their own CDS archives. There is likely to be some bugtail to pass all the tests, this is out of scope for this basic support. We need to pull some fixes from mainline to make this work going smoother.
> 
> I have also enabled Zero Hotspot build in GHA back to keep it buildable.
> 
> Additional testing:
>  - [x] Linux x86_64 zero fastdebug, build works
>  - [x] Linux x86_64 zero fastdebug, bootcycle build works

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'lworld' into JDK-8376103-zero-support
 - Merge branch 'lworld' into JDK-8376103-zero-support
 - Build works
 - Basic Zero build is working

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

Changes: https://git.openjdk.org/valhalla/pull/1943/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1943&range=02
  Stats: 49 lines in 7 files changed: 29 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1943.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1943/head:pull/1943

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

From mcimadamore at openjdk.org  Wed Feb  4 09:57:41 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Feb 2026 09:57:41 GMT
Subject: RFR: [type-classes] 8377123: Add SIZE and BYTES static fields to
 UnsignedInt
In-Reply-To: <Y3wToYG3mIX6NdR1OHCFNMcJ4p8PFd9xRNz8mnfyrWM=.4ee23942-8572-44d0-99c7-8fd04e0d5e20@github.com>
References: <Y3wToYG3mIX6NdR1OHCFNMcJ4p8PFd9xRNz8mnfyrWM=.4ee23942-8572-44d0-99c7-8fd04e0d5e20@github.com>
Message-ID: <XaURbxP3kWM_-e-homSYgTC1kknqumdR7AMJORbkO9M=.c789ba35-fb5d-4ea7-814d-a5f77f374532@github.com>

On Tue, 3 Feb 2026 23:23:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add SIZE and BYTES fields to UnsignedInt, analagous to those fields from java.lang.Integer.

Looks good -- not sure if we should mention the word "flat" anywhere (e.g. in the field name, or in the javadoc) -- after all, an UnsignedInt instance is 4 bytes only when flattened and null-restricted. Maybe MIN_SIZE/MIN_BYTES :-)

We can also settle on the name later...

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

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2028#pullrequestreview-3750077360

From mchevalier at openjdk.org  Wed Feb  4 10:41:33 2026
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 4 Feb 2026 10:41:33 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v3]
In-Reply-To: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
Message-ID: <zbf2dTKAy08E07OXT3gvZP_lgZoklwKfXzGAwlhRDUg=.800da602-1ac2-4c3b-96ad-01294b746557@github.com>

> Some code added by [JDK-8372700](https://bugs.openjdk.org/browse/JDK-8372700) can compute the constant value of a field of a (flatten) element in a flat array. We get a crash when the element of the array is known to be `null`, and so the field doesn't exist.
> 
> So, let's just check in `ciConstant ciFlatArray::field_value(int index, ciField* field)` whether we get a null constant before interpreting it as a `ciInstance` and trying to retrieve a field from there. This should be enough since a `ciObject` is (directly) derived by `ciNullObject`, `ciInstance` and `ciArray`. Since we are looking up a value of a flat array, an element cannot be a `ciArray` (arrays have identities and can't be contained in a flat array). After looking up whether the flat array element is null, the `obj->as_instance()` cast acts as an assert, should we ever add another derived class from `ciObject`.
> 
> In case of a null array element, `field_value` simply returns an invalid `ciConstant`.
> 
> Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks good.
> 
> Thanks,
> Marc

Marc Chevalier 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 14 additional commits since the last revision:

 - Addressing more comments
 - Merge
 - Some reviews
 - Details
 - exception handling
 - oops
 - Also cache correctly whole stable fields
 - fix comment
 - Remove debug
 - ShouldNotReachHere
 - ... and 4 more: https://git.openjdk.org/valhalla/compare/b5dd0de7...34be1bd4

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1923/files
  - new: https://git.openjdk.org/valhalla/pull/1923/files/99c32a32..34be1bd4

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

  Stats: 109131 lines in 3695 files changed: 42082 ins; 42427 del; 24622 mod
  Patch: https://git.openjdk.org/valhalla/pull/1923.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1923/head:pull/1923

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

From mchevalier at openjdk.org  Wed Feb  4 10:41:37 2026
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 4 Feb 2026 10:41:37 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v2]
In-Reply-To: <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <o04pcdsUHYUmnrBXoGMAw_-7HD4jF0QTKUb3SVVGSjM=.4127cdaf-15e5-48ce-8506-893fa17f22e2@github.com>
 <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>
Message-ID: <wOokYDJcbDDJ01Z2OL3tITlPbKDiw2PAOIByl0R27gI=.82ce6422-7b3c-4ca1-b970-7d63923fc88e@github.com>

On Mon, 2 Feb 2026 16:34:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Details
>>  - exception handling
>>  - oops
>>  - Also cache correctly whole stable fields
>>  - fix comment
>>  - Remove debug
>>  - ShouldNotReachHere
>>  - explicit casts
>>  - Clean up
>>  - expand_constant
>
> src/hotspot/share/ci/ciInstance.cpp line 86:
> 
>> 84:         InstanceKlass* holder = InstanceKlass::cast(obj->klass());
>> 85:         int index = -1;
>> 86:         for (JavaFieldStream fs(holder); !fs.done(); fs.next()) {
> 
> My latest PR should include a `_layout_kind` in the `ciField` object, can you use it?

I've tried something. It sure looks nicer.

> src/hotspot/share/ci/ciInstance.cpp line 95:
> 
>> 93:         InlineLayoutInfo* layout_info = holder->inline_layout_info_adr(index);
>> 94:         InlineKlass* vk = layout_info->klass();
>> 95:         oop res = vk->read_payload_from_addr(obj, offset, layout_info->kind(), THREAD);
> 
> It seems to imply that this access is required to be atomic, what if it is a non-atomic field?

I think the problem isn't here, but in `field_value`: in case we need a non-atomic field, we don't need to find the containing field and cache that. If the containing field turns out not to be atomic, we can simply get the leaf field directly, and cache that. For now, I've made an error to ask for a flat declared field in case it's non-atomic: one probably want/should (but at least can) query the leaf fields individually.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2763325289
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2763334575

From qamai at openjdk.org  Wed Feb  4 10:57:03 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 10:57:03 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v2]
In-Reply-To: <wOokYDJcbDDJ01Z2OL3tITlPbKDiw2PAOIByl0R27gI=.82ce6422-7b3c-4ca1-b970-7d63923fc88e@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <o04pcdsUHYUmnrBXoGMAw_-7HD4jF0QTKUb3SVVGSjM=.4127cdaf-15e5-48ce-8506-893fa17f22e2@github.com>
 <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>
 <wOokYDJcbDDJ01Z2OL3tITlPbKDiw2PAOIByl0R27gI=.82ce6422-7b3c-4ca1-b970-7d63923fc88e@github.com>
Message-ID: <Nk8Xpx_z3rgY79yxbtW3yXvdKrszyEX1_VzOgzYCclU=.8b29831d-3e18-4dd8-9310-66268072c439@github.com>

On Wed, 4 Feb 2026 10:38:24 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/ci/ciInstance.cpp line 95:
>> 
>>> 93:         InlineLayoutInfo* layout_info = holder->inline_layout_info_adr(index);
>>> 94:         InlineKlass* vk = layout_info->klass();
>>> 95:         oop res = vk->read_payload_from_addr(obj, offset, layout_info->kind(), THREAD);
>> 
>> It seems to imply that this access is required to be atomic, what if it is a non-atomic field?
>
> I think the problem isn't here, but in `field_value`: in case we need a non-atomic field, we don't need to find the containing field and cache that. If the containing field turns out not to be atomic, we can simply get the leaf field directly, and cache that. For now, I've made an error to ask for a flat declared field in case it's non-atomic: one probably want/should (but at least can) query the leaf fields individually.

What if we have something like this:

    @Stable
    static final VeryLargeValueType[] ARRAY = new null-free-non-atomic VeryLargeValyeType[100];

The program uses a non-atomic layout because it will not do racy accesses on this array, but the compiler may, and what should we do in this case? Probably just give up?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2763396079

From qamai at openjdk.org  Wed Feb  4 11:01:45 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 11:01:45 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v3]
In-Reply-To: <zbf2dTKAy08E07OXT3gvZP_lgZoklwKfXzGAwlhRDUg=.800da602-1ac2-4c3b-96ad-01294b746557@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <zbf2dTKAy08E07OXT3gvZP_lgZoklwKfXzGAwlhRDUg=.800da602-1ac2-4c3b-96ad-01294b746557@github.com>
Message-ID: <f0QG7Z85RoDFn3_izoV-lLfvWODkKokJqCjoE7WSMcI=.d0f1b74b-8830-4b31-b70f-a698c725ad4d@github.com>

On Wed, 4 Feb 2026 10:41:33 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Some code added by [JDK-8372700](https://bugs.openjdk.org/browse/JDK-8372700) can compute the constant value of a field of a (flatten) element in a flat array. We get a crash when the element of the array is known to be `null`, and so the field doesn't exist.
>> 
>> So, let's just check in `ciConstant ciFlatArray::field_value(int index, ciField* field)` whether we get a null constant before interpreting it as a `ciInstance` and trying to retrieve a field from there. This should be enough since a `ciObject` is (directly) derived by `ciNullObject`, `ciInstance` and `ciArray`. Since we are looking up a value of a flat array, an element cannot be a `ciArray` (arrays have identities and can't be contained in a flat array). After looking up whether the flat array element is null, the `obj->as_instance()` cast acts as an assert, should we ever add another derived class from `ciObject`.
>> 
>> In case of a null array element, `field_value` simply returns an invalid `ciConstant`.
>> 
>> Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks good.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier 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 14 additional commits since the last revision:
> 
>  - Addressing more comments
>  - Merge
>  - Some reviews
>  - Details
>  - exception handling
>  - oops
>  - Also cache correctly whole stable fields
>  - fix comment
>  - Remove debug
>  - ShouldNotReachHere
>  - ... and 4 more: https://git.openjdk.org/valhalla/compare/d9a6c30f...34be1bd4

Thanks, I think it looks good overall, I only have the concern about stable non-atomic arrays left.

src/hotspot/share/ci/ciInstance.cpp line 65:

> 63: // ciInstance::field_value_impl
> 64: ciConstant ciInstance::field_value_impl(ciField* field) {
> 65:   BasicType field_btype = field->type()->basic_type();

Just a very little nitpick: We often call the `BasicType` of something `bt`.

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

PR Review: https://git.openjdk.org/valhalla/pull/1923#pullrequestreview-3750371092
PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2763410008

From mchevalier at openjdk.org  Wed Feb  4 12:20:18 2026
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 4 Feb 2026 12:20:18 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v3]
In-Reply-To: <f0QG7Z85RoDFn3_izoV-lLfvWODkKokJqCjoE7WSMcI=.d0f1b74b-8830-4b31-b70f-a698c725ad4d@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <zbf2dTKAy08E07OXT3gvZP_lgZoklwKfXzGAwlhRDUg=.800da602-1ac2-4c3b-96ad-01294b746557@github.com>
 <f0QG7Z85RoDFn3_izoV-lLfvWODkKokJqCjoE7WSMcI=.d0f1b74b-8830-4b31-b70f-a698c725ad4d@github.com>
Message-ID: <Usg9cFFGG0tQxHhBG-U7eTviSHMPaqW5iTlMf6Zlaso=.f316cf78-deb7-4e1c-b6c0-a2f594c4a167@github.com>

On Wed, 4 Feb 2026 10:57:49 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Marc Chevalier 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 14 additional commits since the last revision:
>> 
>>  - Addressing more comments
>>  - Merge
>>  - Some reviews
>>  - Details
>>  - exception handling
>>  - oops
>>  - Also cache correctly whole stable fields
>>  - fix comment
>>  - Remove debug
>>  - ShouldNotReachHere
>>  - ... and 4 more: https://git.openjdk.org/valhalla/compare/b50e1f43...34be1bd4
>
> src/hotspot/share/ci/ciInstance.cpp line 65:
> 
>> 63: // ciInstance::field_value_impl
>> 64: ciConstant ciInstance::field_value_impl(ciField* field) {
>> 65:   BasicType field_btype = field->type()->basic_type();
> 
> Just a very little nitpick: We often call the `BasicType` of something `bt`.

I'm fine renaming it, it was just like that before and I've kept it. But I like that it mentions of what it is the basic type. I've seen things as `bt2` and wasn't thrilled. Is `field_bt` fine for you (or `bt_field`)? Anyway, there aren't that many stuff going on in this method, so I'd be fine with a simple `bt`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2763721247

From qamai at openjdk.org  Wed Feb  4 12:24:07 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 12:24:07 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v3]
In-Reply-To: <Usg9cFFGG0tQxHhBG-U7eTviSHMPaqW5iTlMf6Zlaso=.f316cf78-deb7-4e1c-b6c0-a2f594c4a167@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <zbf2dTKAy08E07OXT3gvZP_lgZoklwKfXzGAwlhRDUg=.800da602-1ac2-4c3b-96ad-01294b746557@github.com>
 <f0QG7Z85RoDFn3_izoV-lLfvWODkKokJqCjoE7WSMcI=.d0f1b74b-8830-4b31-b70f-a698c725ad4d@github.com>
 <Usg9cFFGG0tQxHhBG-U7eTviSHMPaqW5iTlMf6Zlaso=.f316cf78-deb7-4e1c-b6c0-a2f594c4a167@github.com>
Message-ID: <SCe4rj9Gqi9-w8yPnkKWhdHTsJJGrsLVbb26D7qCtx0=.adb2da03-e923-49b1-abfb-a5089bdd15ca@github.com>

On Wed, 4 Feb 2026 12:17:02 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/ci/ciInstance.cpp line 65:
>> 
>>> 63: // ciInstance::field_value_impl
>>> 64: ciConstant ciInstance::field_value_impl(ciField* field) {
>>> 65:   BasicType field_btype = field->type()->basic_type();
>> 
>> Just a very little nitpick: We often call the `BasicType` of something `bt`.
>
> I'm fine renaming it, it was just like that before and I've kept it. But I like that it mentions of what it is the basic type. I've seen things as `bt2` and wasn't thrilled. Is `field_bt` fine for you (or `bt_field`)? Anyway, there aren't that many stuff going on in this method, so I'd be fine with a simple `bt`.

`field_bt` seems to be the choice most consistent with other usages.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2763734433

From mchevalier at openjdk.org  Wed Feb  4 12:39:49 2026
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 4 Feb 2026 12:39:49 GMT
Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed:
 bad cast [v2]
In-Reply-To: <Nk8Xpx_z3rgY79yxbtW3yXvdKrszyEX1_VzOgzYCclU=.8b29831d-3e18-4dd8-9310-66268072c439@github.com>
References: <I9s2yFvX7dsG1aZAw4K4VBURsXyfz7VZMvJInwzUirQ=.03ff8560-ad82-44e6-9f93-ef1f9198e7b8@github.com>
 <o04pcdsUHYUmnrBXoGMAw_-7HD4jF0QTKUb3SVVGSjM=.4127cdaf-15e5-48ce-8506-893fa17f22e2@github.com>
 <p-lvvOrPvscaNBdYgiRY6Wg95JMr5lN2B9jRM488yZs=.0e4754f4-a1f5-4dae-994e-efa0140cf64e@github.com>
 <wOokYDJcbDDJ01Z2OL3tITlPbKDiw2PAOIByl0R27gI=.82ce6422-7b3c-4ca1-b970-7d63923fc88e@github.com>
 <Nk8Xpx_z3rgY79yxbtW3yXvdKrszyEX1_VzOgzYCclU=.8b29831d-3e18-4dd8-9310-66268072c439@github.com>
Message-ID: <_BqAASZwS-MqNtx2_H0xuLAe0BdqL1Lga39gn7C-2Us=.21ae4c16-bc91-4b6b-a608-7b1f8b74971a@github.com>

On Wed, 4 Feb 2026 10:53:59 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> I think the problem isn't here, but in `field_value`: in case we need a non-atomic field, we don't need to find the containing field and cache that. If the containing field turns out not to be atomic, we can simply get the leaf field directly, and cache that. For now, I've made an error to ask for a flat declared field in case it's non-atomic: one probably want/should (but at least can) query the leaf fields individually.
>
> What if we have something like this:
> 
>     @Stable
>     static final VeryLargeValueType[] ARRAY = new null-free-non-atomic VeryLargeValyeType[100];
> 
> The program uses a non-atomic layout because it will not do racy accesses on this array, but the compiler may, and what should we do in this case? Probably just give up?

I was writing an elaborate answer exploring different options, but I fear I'm not sure enough what the compiler must honor in such a case. Or rather what guarantees are still kept by non-atomicity.

I think the surely simplest, and safe strategy is indeed not to do this fancy expansion if we are loading from a non atomic array. A simple `&& aryptr->is_atomic()` in `compile.cpp` would do that.nn

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2763795325

From qamai at openjdk.org  Wed Feb  4 12:49:25 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 12:49:25 GMT
Subject: [lworld] RFR: 8376791: [lworld] C2 compilation hits assert(!not_flat
 || !is_flat()) failed: inconsistency
Message-ID: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>

Hi,

The issue is that we blindly assume that the vararg argument is a not flat and not null-free array. This misses 2 factors:

- With the introduction of nullable flat layouts, it is possible to flatten a default array allocation (e.g. `new Integer[4]`)
- The node may have its own speculative type already, we need to make sure our optimistic guess does not contradict the existing speculation.

As a result, I changed the implementation to assume that the exact type is the default refined type of the declared parameter type.

Testing:

- [ ] tier1-4,valhalla-comp-stress, Linux-x64

Please kindly review, thanks a lot.

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

Commit messages:
 - conflicting types when speculate on vararg arguments

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

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

From thartmann at openjdk.org  Wed Feb  4 12:56:35 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 4 Feb 2026 12:56:35 GMT
Subject: [lworld] RFR: 8376733: [lworld] Inconsistent result of
 Invoke::declared_type triggers assert in profiling
Message-ID: <TzLN7lPwoJDBMkyY5sCY2oH7mVnS7Oyx9OGpB3lL-84=.367f6412-6b0a-4252-af1f-43e8e00ee8ce@github.com>

Old mainline fix [JDK-8134389](https://bugs.openjdk.org/browse/JDK-8134389) modified code in `Invoke::declared_type` to not use the return type of the target signature but use the declared signature instead (see [changeset](https://hg.openjdk.org/jdk9/jdk9/hotspot/rev/4191b33b3629) for details). This was needed for method handle call sites to return `java/lang/invoke/CallSite` instead of `java/lang/Object` or whatever the target method return type would look like. The test `compiler/jsr292/TestArrayReturnType.java` still reliably triggers this scenario.

Now the problem is that the return type is re-computed on every call to `Invoke::declared_type` but it might actually change from unloaded to loaded in-between and therefore different `ciType` objects will be returned. In the failing case, the return type first is
`<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=false ident=1498 address=0x00007ae57d775728>` 
and later it's `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=true ident=1508 address=0x00007ae57d7762a8>` (note the different `loaded` property). This leads to an assertion failure in profiling because we invoke CHA to improve a type that's already final because when we checked the type earlier, it was still unloaded.

I think it's a general rule that the compiler interface needs to guarantee consistency of types during compilation and therefore I adjusted the code to only compute the return type once. This is a mainline issue and could be fixed in mainline as well. However, as far as I can tell, only Valhalla is currently affected because the Valhalla specific array load/store profiling uses `LIRGenerator::profile_type` in more cases. Let's therefore only fix it in Valhalla for now.

Thanks,
Tobias

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

Commit messages:
 - 8376733: [lworld] Inconsistent result of Invoke::declared_type triggers assert in profiling

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

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

From thartmann at openjdk.org  Wed Feb  4 13:11:30 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 4 Feb 2026 13:11:30 GMT
Subject: [lworld] RFR: 8376791: [lworld] C2 compilation hits
 assert(!not_flat || !is_flat()) failed: inconsistency
In-Reply-To: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
References: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
Message-ID: <ZJDyGHNGjWqrpL1LObN2qMzbFMzByJVojroaWMESsW0=.adf8944c-428a-417e-82f6-35492bbaec75@github.com>

On Wed, 4 Feb 2026 12:41:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue is that we blindly assume that the vararg argument is a not flat and not null-free array. This misses 2 factors:
> 
> - With the introduction of nullable flat layouts, it is possible to flatten a default array allocation (e.g. `new Integer[4]`)
> - The node may have its own speculative type already, we need to make sure our optimistic guess does not contradict the existing speculation.
> 
> As a result, I changed the implementation to assume that the exact type is the default refined type of the declared parameter type.
> 
> Testing:
> 
> - [ ] tier1-4,valhalla-comp-stress, Linux-x64
> 
> Please kindly review, thanks a lot.

Thanks for fixing this. Looks good to me otherwise!

src/hotspot/share/opto/parse1.cpp line 667:

> 665:       improved_type = improved_type->join_speculative(t)->is_ptr();
> 666:       if (improved_type != t) {
> 667:         Node* cast = _gvn.transform(new CheckCastPPNode(control(), parm, improved_type, ConstraintCastNode::DependencyType::NonFloatingNarrowing));

Can't we use default `FloatingNarrowing` here?

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2030#pullrequestreview-3750976023
PR Review Comment: https://git.openjdk.org/valhalla/pull/2030#discussion_r2763938685

From coleenp at openjdk.org  Wed Feb  4 13:13:42 2026
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Feb 2026 13:13:42 GMT
Subject: [lworld] RFR: 8376103: [lworld] Basic Zero support [v3]
In-Reply-To: <4qp3Dh1-SmlwCaXvUI61EI5ahRa_tlg5RHR_kGBi--E=.e5977a1b-0988-425f-9976-0832c3e9d8ec@github.com>
References: <cMhg_6DEG3p6LtO-M2KaX7X-o8BVvmccLZ13evyTXF8=.7257fd42-4474-41d5-855f-28d203aed19c@github.com>
 <4qp3Dh1-SmlwCaXvUI61EI5ahRa_tlg5RHR_kGBi--E=.e5977a1b-0988-425f-9976-0832c3e9d8ec@github.com>
Message-ID: <jWZ0bm-LroxC-vkZO8hcCngj7_KhpwhIc9Hsu1VBu_w=.a00dd19c-e624-4a0f-82cc-a92e3a2ffe0f@github.com>

On Wed, 4 Feb 2026 09:16:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> On the way to stabilizing Valhalla for inclusion into mainline, we want to have Zero builds at least buildable and lightly runnable, e.g. for creating their own CDS archives. There is likely to be some bugtail to pass all the tests, this is out of scope for this basic support. We need to pull some fixes from mainline to make this work going smoother.
>> 
>> I have also enabled Zero Hotspot build in GHA back to keep it buildable.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 zero fastdebug, build works
>>  - [x] Linux x86_64 zero fastdebug, bootcycle build works
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'lworld' into JDK-8376103-zero-support
>  - Merge branch 'lworld' into JDK-8376103-zero-support
>  - Build works
>  - Basic Zero build is working

Looks good. Thanks for fixing zero.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1943#pullrequestreview-3750993511

From qamai at openjdk.org  Wed Feb  4 13:25:30 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 13:25:30 GMT
Subject: [lworld] RFR: 8376791: [lworld] C2 compilation hits
 assert(!not_flat || !is_flat()) failed: inconsistency [v2]
In-Reply-To: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
References: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
Message-ID: <iiOpM60E9KsKBC_5tug1k7z6kq9H4X595dHJHkrWGjA=.21625316-b67e-47ff-88fd-5e242453ada9@github.com>

> Hi,
> 
> The issue is that we blindly assume that the vararg argument is a not flat and not null-free array. This misses 2 factors:
> 
> - With the introduction of nullable flat layouts, it is possible to flatten a default array allocation (e.g. `new Integer[4]`)
> - The node may have its own speculative type already, we need to make sure our optimistic guess does not contradict the existing speculation.
> 
> As a result, I changed the implementation to assume that the exact type is the default refined type of the declared parameter type.
> 
> Testing:
> 
> - [ ] tier1-4,valhalla-comp-stress, Linux-x64
> 
> Please kindly review, thanks a lot.

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

  speculative may not be an aryptr

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2030/files
  - new: https://git.openjdk.org/valhalla/pull/2030/files/862a8aea..887017b3

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

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

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

From qamai at openjdk.org  Wed Feb  4 13:34:28 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 13:34:28 GMT
Subject: [lworld] RFR: 8376791: [lworld] C2 compilation hits
 assert(!not_flat || !is_flat()) failed: inconsistency [v3]
In-Reply-To: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
References: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
Message-ID: <1vR6fZTXZJePK-l9hYECorhrywbQYvDhqrvQgKknH7s=.88952a50-4127-4542-be91-4e05d0eb2997@github.com>

> Hi,
> 
> The issue is that we blindly assume that the vararg argument is a not flat and not null-free array. This misses 2 factors:
> 
> - With the introduction of nullable flat layouts, it is possible to flatten a default array allocation (e.g. `new Integer[4]`)
> - The node may have its own speculative type already, we need to make sure our optimistic guess does not contradict the existing speculation.
> 
> As a result, I changed the implementation to assume that the exact type is the default refined type of the declared parameter type.
> 
> Testing:
> 
> - [ ] tier1-4,valhalla-comp-stress, Linux-x64
> 
> Please kindly review, thanks a lot.

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

  Only for top-most method

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2030/files
  - new: https://git.openjdk.org/valhalla/pull/2030/files/887017b3..b9b87af6

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

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

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

From david.simms at oracle.com  Wed Feb  4 13:36:25 2026
From: david.simms at oracle.com (David Simms)
Date: Wed, 4 Feb 2026 14:36:25 +0100
Subject: CFV: New Valhalla Committer: Chris Plummer
In-Reply-To: <SJ2PR10MB7669723990843EFA731C687FA28DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <e129b780-1890-4334-bce4-610342ca0961@oracle.com>
 <SJ2PR10MB7669723990843EFA731C687FA28DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <d5b4ad7a-55d2-4ff3-9bbf-66d576e4f9e5@oracle.com>


You are correct, the deadline date should read 29th of January, 2026.

On 2026-01-16 18:22, Chen Liang wrote:
> Hi David, is the due date in this mail correct? I assume it should be 
> 29th of January, 2026. If that is the correct date, then I cast a vote:
>
> Vote: yes
>
> Chen Liang
>
> Confidential- Oracle Internal
> ------------------------------------------------------------------------
> *From:* valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of 
> David Simms <david.simms at oracle.com>
> *Sent:* Thursday, January 15, 2026 10:23 AM
> *To:* valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
> *Subject:* CFV: New Valhalla Committer: Chris Plummer
> |I hereby nominate *Chris Plummer* to *Valhalla* Committer. Chris is a 
> long time member of the OpenJDK project, with over 400 commits in the 
> mainline[1]. Votes are due by 29th of December, 18:00z. Only current 
> *Valhalla* Committers [2] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list. For 
> Lazy Consensus voting instructions, see [3]. *David Simms* [1] 
> https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits 
> <https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits> 
> [2] https://openjdk.org/census <https://openjdk.org/census> [3] 
> https://openjdk.org/projects/#committer-vote 
> <https://openjdk.org/projects/#committer-vote>|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20260204/35918dcc/attachment-0001.htm>

From david.simms at oracle.com  Wed Feb  4 13:40:59 2026
From: david.simms at oracle.com (David Simms)
Date: Wed, 4 Feb 2026 14:40:59 +0100
Subject: Result: CFV: New Valhalla Committer: Chris Plummer
Message-ID: <04cb133d-7e27-4ad7-b185-f2b9eee10ec8@oracle.com>

|Voting for *Chris Plummer* [1] is now closed. Yes: *7* Veto: 0 Abstain: 
*0* According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. *David Simms* [1] 
https://mail.openjdk.org/pipermail/valhalla-dev/2026-January/017517.html|

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

From qamai at openjdk.org  Wed Feb  4 13:42:22 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 13:42:22 GMT
Subject: [lworld] RFR: 8376791: [lworld] C2 compilation hits
 assert(!not_flat || !is_flat()) failed: inconsistency [v4]
In-Reply-To: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
References: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
Message-ID: <KxEUgrjQFlV8G_J1xp20VBBGi9qnAnd3DyBZ7Kh_-LU=.4cda9066-5878-4cc3-bae1-d31544729fb2@github.com>

> Hi,
> 
> The issue is that we blindly assume that the vararg argument is a not flat and not null-free array. This misses 2 factors:
> 
> - With the introduction of nullable flat layouts, it is possible to flatten a default array allocation (e.g. `new Integer[4]`)
> - The node may have its own speculative type already, we need to make sure our optimistic guess does not contradict the existing speculation.
> 
> As a result, I changed the implementation to assume that the exact type is the default refined type of the declared parameter type.
> 
> Testing:
> 
> - [ ] tier1-4,valhalla-comp-stress, Linux-x64
> 
> Please kindly review, thanks a lot.

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

  comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2030/files
  - new: https://git.openjdk.org/valhalla/pull/2030/files/b9b87af6..6d1ee92c

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

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

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

From qamai at openjdk.org  Wed Feb  4 13:42:25 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 13:42:25 GMT
Subject: [lworld] RFR: 8376791: [lworld] C2 compilation hits
 assert(!not_flat || !is_flat()) failed: inconsistency [v4]
In-Reply-To: <ZJDyGHNGjWqrpL1LObN2qMzbFMzByJVojroaWMESsW0=.adf8944c-428a-417e-82f6-35492bbaec75@github.com>
References: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
 <ZJDyGHNGjWqrpL1LObN2qMzbFMzByJVojroaWMESsW0=.adf8944c-428a-417e-82f6-35492bbaec75@github.com>
Message-ID: <pj4BPg7hW7TlSuTJvyyLNOOatspspf9Eynk3cNq9YTM=.712ec486-abe4-43f5-8c5d-7023e52a3dc4@github.com>

On Wed, 4 Feb 2026 13:07:17 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:
>> 
>>   comments
>
> src/hotspot/share/opto/parse1.cpp line 667:
> 
>> 665:       improved_type = improved_type->join_speculative(t)->is_ptr();
>> 666:       if (improved_type != t) {
>> 667:         Node* cast = _gvn.transform(new CheckCastPPNode(control(), parm, improved_type, ConstraintCastNode::DependencyType::NonFloatingNarrowing));
> 
> Can't we use default `FloatingNarrowing` here?

Thanks for your speedy review. Theoretically, it makes more sense since this speculation comes with the method invocation, and a method invocation does not float. Practically, it does not make any difference because this speculation should only be practiced when we are the top-most method. In that case, there is no where else to hoist to so it makes no difference whether the cast is floating. I have added a comment explaining why this speculation only makes sense when we are the top-most method.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2030#discussion_r2764075205

From thartmann at openjdk.org  Wed Feb  4 13:47:07 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 4 Feb 2026 13:47:07 GMT
Subject: [lworld] RFR: 8376791: [lworld] C2 compilation hits
 assert(!not_flat || !is_flat()) failed: inconsistency [v4]
In-Reply-To: <KxEUgrjQFlV8G_J1xp20VBBGi9qnAnd3DyBZ7Kh_-LU=.4cda9066-5878-4cc3-bae1-d31544729fb2@github.com>
References: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
 <KxEUgrjQFlV8G_J1xp20VBBGi9qnAnd3DyBZ7Kh_-LU=.4cda9066-5878-4cc3-bae1-d31544729fb2@github.com>
Message-ID: <d5m4_vxp6DMn5rGoGmquIv349F-0MPy4YzCfBl6EqZE=.f2489433-e085-422e-aaa6-042c541678af@github.com>

On Wed, 4 Feb 2026 13:42:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> The issue is that we blindly assume that the vararg argument is a not flat and not null-free array. This misses 2 factors:
>> 
>> - With the introduction of nullable flat layouts, it is possible to flatten a default array allocation (e.g. `new Integer[4]`)
>> - The node may have its own speculative type already, we need to make sure our optimistic guess does not contradict the existing speculation.
>> 
>> As a result, I changed the implementation to assume that the exact type is the default refined type of the declared parameter type.
>> 
>> Testing:
>> 
>> - [ ] tier1-4,valhalla-comp-stress, Linux-x64
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments

Thanks, the new comment looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2030#pullrequestreview-3751154175

From thartmann at openjdk.org  Wed Feb  4 13:47:08 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 4 Feb 2026 13:47:08 GMT
Subject: [lworld] RFR: 8376791: [lworld] C2 compilation hits
 assert(!not_flat || !is_flat()) failed: inconsistency [v4]
In-Reply-To: <pj4BPg7hW7TlSuTJvyyLNOOatspspf9Eynk3cNq9YTM=.712ec486-abe4-43f5-8c5d-7023e52a3dc4@github.com>
References: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
 <ZJDyGHNGjWqrpL1LObN2qMzbFMzByJVojroaWMESsW0=.adf8944c-428a-417e-82f6-35492bbaec75@github.com>
 <pj4BPg7hW7TlSuTJvyyLNOOatspspf9Eynk3cNq9YTM=.712ec486-abe4-43f5-8c5d-7023e52a3dc4@github.com>
Message-ID: <x_KxGkjDJ2sFLaNX-TriOqF9kPb--UjggGA5NfqysVg=.ec1a47e8-6229-40c1-ba67-d7da79c5fdda@github.com>

On Wed, 4 Feb 2026 13:39:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/parse1.cpp line 667:
>> 
>>> 665:       improved_type = improved_type->join_speculative(t)->is_ptr();
>>> 666:       if (improved_type != t) {
>>> 667:         Node* cast = _gvn.transform(new CheckCastPPNode(control(), parm, improved_type, ConstraintCastNode::DependencyType::NonFloatingNarrowing));
>> 
>> Can't we use default `FloatingNarrowing` here?
>
> Thanks for your speedy review. Theoretically, it makes more sense since this speculation comes with the method invocation, and a method invocation does not float. Practically, it does not make any difference because this speculation should only be practiced when we are the top-most method. In that case, there is no where else to hoist to so it makes no difference whether the cast is floating. I have added a comment explaining why this speculation only makes sense when we are the top-most method.

That makes sense, thanks for the details.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2030#discussion_r2764095594

From jlahoda at openjdk.org  Wed Feb  4 13:57:28 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Feb 2026 13:57:28 GMT
Subject: RFR: Show null restriction markers in javadoc. [v2]
In-Reply-To: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
References: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
Message-ID: <kz-Mi3C1fA3X-T8foXnANWJVEZq-4sHH_pllvJ7RROw=.9ecccaba-210c-4cd4-9ff9-d951e0bae426@github.com>

> Adds null markers inside generated javadoc like this:
> <img width="1144" height="528" alt="null-markers-javadoc" src="https://github.com/user-attachments/assets/b97736ff-f240-4c88-b874-32a8f7c8743c" />
> 
> Not sure if this is the ideal UI, and this is the best way to do implement it.
> 
> I didn't add tests yet, given the representation may change with experience.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adding a test.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2022/files
  - new: https://git.openjdk.org/valhalla/pull/2022/files/51351369..c3d87723

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

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

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

From shade at openjdk.org  Wed Feb  4 14:09:24 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Feb 2026 14:09:24 GMT
Subject: [lworld] RFR: 8376103: [lworld] Basic Zero support [v3]
In-Reply-To: <jWZ0bm-LroxC-vkZO8hcCngj7_KhpwhIc9Hsu1VBu_w=.a00dd19c-e624-4a0f-82cc-a92e3a2ffe0f@github.com>
References: <cMhg_6DEG3p6LtO-M2KaX7X-o8BVvmccLZ13evyTXF8=.7257fd42-4474-41d5-855f-28d203aed19c@github.com>
 <4qp3Dh1-SmlwCaXvUI61EI5ahRa_tlg5RHR_kGBi--E=.e5977a1b-0988-425f-9976-0832c3e9d8ec@github.com>
 <jWZ0bm-LroxC-vkZO8hcCngj7_KhpwhIc9Hsu1VBu_w=.a00dd19c-e624-4a0f-82cc-a92e3a2ffe0f@github.com>
Message-ID: <-CPg6BusnndjW-Vzg_absBQDYF2ZqTeLf08QIQSaLh4=.ef13bbf1-cfee-444a-bfa0-1b305c95fe73@github.com>

On Wed, 4 Feb 2026 13:10:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'lworld' into JDK-8376103-zero-support
>>  - Merge branch 'lworld' into JDK-8376103-zero-support
>>  - Build works
>>  - Basic Zero build is working
>
> Looks good. Thanks for fixing zero.

Thanks @coleenp! Let me integrate it then.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1943#issuecomment-3847655665

From duke at openjdk.org  Wed Feb  4 14:09:26 2026
From: duke at openjdk.org (duke)
Date: Wed, 4 Feb 2026 14:09:26 GMT
Subject: [lworld] RFR: 8376103: [lworld] Basic Zero support [v3]
In-Reply-To: <4qp3Dh1-SmlwCaXvUI61EI5ahRa_tlg5RHR_kGBi--E=.e5977a1b-0988-425f-9976-0832c3e9d8ec@github.com>
References: <cMhg_6DEG3p6LtO-M2KaX7X-o8BVvmccLZ13evyTXF8=.7257fd42-4474-41d5-855f-28d203aed19c@github.com>
 <4qp3Dh1-SmlwCaXvUI61EI5ahRa_tlg5RHR_kGBi--E=.e5977a1b-0988-425f-9976-0832c3e9d8ec@github.com>
Message-ID: <-syxkdhjvB8DI3Us5GZbrJv4wMS_HCQTftI_GqXsAvQ=.d9b5b42d-bda2-49ba-b6a1-0098cea8b7ea@github.com>

On Wed, 4 Feb 2026 09:16:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> On the way to stabilizing Valhalla for inclusion into mainline, we want to have Zero builds at least buildable and lightly runnable, e.g. for creating their own CDS archives. There is likely to be some bugtail to pass all the tests, this is out of scope for this basic support. We need to pull some fixes from mainline to make this work going smoother.
>> 
>> I have also enabled Zero Hotspot build in GHA back to keep it buildable.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 zero fastdebug, build works
>>  - [x] Linux x86_64 zero fastdebug, bootcycle build works
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'lworld' into JDK-8376103-zero-support
>  - Merge branch 'lworld' into JDK-8376103-zero-support
>  - Build works
>  - Basic Zero build is working

@shipilev 
Your change (at version 5e06e91cf9eb283511edb864d7a8c514abfd93a0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1943#issuecomment-3847674229

From david.simms at oracle.com  Wed Feb  4 14:09:43 2026
From: david.simms at oracle.com (David Simms)
Date: Wed, 4 Feb 2026 15:09:43 +0100
Subject: =?UTF-8?Q?CFV=3A_New_Valhalla_Committer=3A_Joel_Sikstr=C3=B6m?=
Message-ID: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>

|I hereby nominate Joel Sikstr?m to Valhalla Committer. Joel is an 
OpenJDK reviewer with over 50 contributions [1]. Votes are due by 18th 
of February 2026, 14:00z. Only current Valhalla Committers [2] are 
eligible to vote on this nomination. Votes must be cast in the open by 
replying to this mailing list. For Lazy Consensus voting instructions, 
see [3]. David Simms [1] 
https://github.com/search?q=committer-name%3A%22Joel+Sikstr%C3%B6m%22+repo%3Aopenjdk%2Fjdk&type=commits 
[2] https://openjdk.org/census [3] 
https://openjdk.org/projects/#committer-vote|

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

From david.simms at oracle.com  Wed Feb  4 14:10:32 2026
From: david.simms at oracle.com (David Simms)
Date: Wed, 4 Feb 2026 15:10:32 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_Valhalla_Committer=3A_Joel_Sikstr=C3=B6m?=
In-Reply-To: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
References: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
Message-ID: <be182e5a-2bb1-4db3-bc7c-cfe5004c8279@oracle.com>


Vote: yes

On 2026-02-04 15:09, David Simms wrote:
> |I hereby nominate Joel Sikstr?m to Valhalla Committer. Joel is an 
> OpenJDK reviewer with over 50 contributions [1]. Votes are due by 18th 
> of February 2026, 14:00z. Only current Valhalla Committers [2] are 
> eligible to vote on this nomination. Votes must be cast in the open by 
> replying to this mailing list. For Lazy Consensus voting instructions, 
> see [3]. David Simms [1] 
> https://github.com/search?q=committer-name%3A%22Joel+Sikstr%C3%B6m%22+repo%3Aopenjdk%2Fjdk&type=commits 
> [2] https://openjdk.org/census [3] 
> https://openjdk.org/projects/#committer-vote|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20260204/14926d1d/attachment-0001.htm>

From roger.riggs at oracle.com  Wed Feb  4 14:12:15 2026
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 4 Feb 2026 09:12:15 -0500
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_Valhalla_Committer=3A_Joel_Sikstr=C3=B6m?=
In-Reply-To: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
References: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
Message-ID: <397e3b91-20e8-48a0-a086-081dfafeb8af@oracle.com>

Vote: Yes

On 2/4/26 9:09 AM, David Simms wrote:
> |I hereby nominate Joel Sikstr?m to Valhalla Committer.|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20260204/15fa11c2/attachment.htm>

From chen.l.liang at oracle.com  Wed Feb  4 14:29:30 2026
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 4 Feb 2026 14:29:30 +0000
Subject: =?iso-8859-1?Q?Re:_CFV:_New_Valhalla_Committer:_Joel_Sikstr=F6m?=
In-Reply-To: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
References: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
Message-ID: <CH3PR10MB76774CD39E1AB25BD719D961A298A@CH3PR10MB7677.namprd10.prod.outlook.com>

Vote: yes
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Sent: Wednesday, February 4, 2026 8:09 AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Joel Sikstr?m


I hereby nominate Joel Sikstr?m to Valhalla Committer.

Joel is an OpenJDK reviewer with over 50 contributions [1].

Votes are due by 18th of February 2026, 14:00z.

Only current Valhalla Committers [2] are eligible to vote
on this nomination.  Votes must be cast in the open by replying
to this mailing list.

For Lazy Consensus voting instructions, see [3].

David Simms

[1] https://github.com/search?q=committer-name%3A%22Joel+Sikstr%C3%B6m%22+repo%3Aopenjdk%2Fjdk&type=commits
[2] https://openjdk.org/census
[3] https://openjdk.org/projects/#committer-vote

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

From liach at openjdk.org  Wed Feb  4 14:33:39 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 14:33:39 GMT
Subject: RFR: Show null restriction markers in javadoc. [v2]
In-Reply-To: <kz-Mi3C1fA3X-T8foXnANWJVEZq-4sHH_pllvJ7RROw=.9ecccaba-210c-4cd4-9ff9-d951e0bae426@github.com>
References: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
 <kz-Mi3C1fA3X-T8foXnANWJVEZq-4sHH_pllvJ7RROw=.9ecccaba-210c-4cd4-9ff9-d951e0bae426@github.com>
Message-ID: <DSYySJq8LOM8U52912TtUjgFJQyrFVDFoeu1skFHlSI=.9d84de93-249d-4185-9860-e6047dc516d6@github.com>

On Wed, 4 Feb 2026 13:57:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adds null markers inside generated javadoc like this:
>> <img width="1144" height="528" alt="null-markers-javadoc" src="https://github.com/user-attachments/assets/b97736ff-f240-4c88-b874-32a8f7c8743c" />
>> 
>> Not sure if this is the ideal UI, and this is the best way to do implement it.
>> 
>> I didn't add tests yet, given the representation may change with experience.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a test.

New test looks good.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2022#pullrequestreview-3751409683

From tobias.hartmann at oracle.com  Wed Feb  4 14:34:04 2026
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 4 Feb 2026 15:34:04 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_Valhalla_Committer=3A_Joel_Sikstr=C3=B6m?=
In-Reply-To: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
References: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
Message-ID: <ef0a97ca-1e37-4c38-afa2-e65c321ca979@oracle.com>

Vote: yes

Best regards,
Tobias

On 2/4/26 15:09, David Simms wrote:
> |I hereby nominate Joel Sikstr?m to Valhalla Committer. Joel is an OpenJDK reviewer with over 50 contributions [1]. Votes are due by 18th of February 2026, 14:00z. Only current Valhalla Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. David Simms [1] https://github.com/search?q=committer-name%3A%22Joel+Sikstr%C3%B6m%22+repo%3Aopenjdk%2Fjdk&type=commits [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote|
> 
> 


From stefan.karlsson at oracle.com  Wed Feb  4 14:52:34 2026
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Feb 2026 15:52:34 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_Valhalla_Committer=3A_Joel_Sikstr=C3=B6m?=
In-Reply-To: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
References: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
Message-ID: <97c9dab3-bbc0-4664-90b3-fcb6d743b036@oracle.com>

Vote: yes

StefanK

On 2026-02-04 15:09, David Simms wrote:
> |I hereby nominate Joel Sikstr?m to Valhalla Committer. Joel is an 
> OpenJDK reviewer with over 50 contributions [1]. Votes are due by 18th 
> of February 2026, 14:00z. Only current Valhalla Committers [2] are 
> eligible to vote on this nomination. Votes must be cast in the open by 
> replying to this mailing list. For Lazy Consensus voting instructions, 
> see [3]. David Simms [1] 
> https://github.com/search?q=committer-name%3A%22Joel+Sikstr%C3%B6m%22+repo%3Aopenjdk%2Fjdk&type=commits 
> [2] https://openjdk.org/census [3] 
> https://openjdk.org/projects/#committer-vote|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20260204/35055334/attachment.htm>

From liach at openjdk.org  Wed Feb  4 14:58:58 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 14:58:58 GMT
Subject: [lworld] RFR: 8377171: [lworld] Comment warnings for internal valhalla
 annotations
Message-ID: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>

Add some warning comments for value-related annotations in jdk.internal, to discourage their misuse.

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

Commit messages:
 - Warnings for value annotations

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

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

From paul.hubner at oracle.com  Wed Feb  4 15:03:05 2026
From: paul.hubner at oracle.com (Paul Hubner)
Date: Wed, 4 Feb 2026 15:03:05 +0000
Subject: =?iso-8859-1?Q?Re:_CFV:_New_Valhalla_Committer:_Joel_Sikstr=F6m?=
In-Reply-To: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
References: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
Message-ID: <BN8PR10MB3316272630AD56F9355989A28398A@BN8PR10MB3316.namprd10.prod.outlook.com>

Vote: yes

Paul
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Sent: Wednesday, February 4, 2026 3:09 PM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Joel Sikstr?m


I hereby nominate Joel Sikstr?m to Valhalla Committer.

Joel is an OpenJDK reviewer with over 50 contributions [1].

Votes are due by 18th of February 2026, 14:00z.

Only current Valhalla Committers [2] are eligible to vote
on this nomination.  Votes must be cast in the open by replying
to this mailing list.

For Lazy Consensus voting instructions, see [3].

David Simms

[1] https://github.com/search?q=committer-name%3A%22Joel+Sikstr%C3%B6m%22+repo%3Aopenjdk%2Fjdk&type=commits
[2] https://openjdk.org/census
[3] https://openjdk.org/projects/#committer-vote

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

From qamai at openjdk.org  Wed Feb  4 15:04:53 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 15:04:53 GMT
Subject: [lworld] Integrated: 8376791: [lworld] C2 compilation hits
 assert(!not_flat || !is_flat()) failed: inconsistency
In-Reply-To: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
References: <ObFVsArIeA4WKf4naU_cai-iJPB6ohaCp1rnQQSA3gM=.f1f94076-b630-4dbe-959f-11288dcbbeaa@github.com>
Message-ID: <BHpAvqxG2Brq_ecaDkeO-dytV7Jp9C0Y7Xwg9_8Hglc=.ed48b1e0-3e51-476f-9a97-added8b92220@github.com>

On Wed, 4 Feb 2026 12:41:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue is that we blindly assume that the vararg argument is a not flat and not null-free array. This misses 2 factors:
> 
> - With the introduction of nullable flat layouts, it is possible to flatten a default array allocation (e.g. `new Integer[4]`)
> - The node may have its own speculative type already, we need to make sure our optimistic guess does not contradict the existing speculation.
> 
> As a result, I changed the implementation to assume that the exact type is the default refined type of the declared parameter type.
> 
> Testing:
> 
> - [x] tier1-4,valhalla-comp-stress, Linux-x64
> 
> Please kindly review, thanks a lot.

This pull request has now been integrated.

Changeset: 2f212a19
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2f212a19a7ffd9369505af193422845531e2c690
Stats:     43 lines in 2 files changed: 32 ins; 0 del; 11 mod

8376791: [lworld] C2 compilation hits assert(!not_flat || !is_flat()) failed: inconsistency

Reviewed-by: thartmann

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

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

From duke at openjdk.org  Wed Feb  4 15:28:55 2026
From: duke at openjdk.org (David Beaumont)
Date: Wed, 4 Feb 2026 15:28:55 GMT
Subject: [lworld] RFR: 8377162: [lworld] getResourceAsStream() doesn't work in
 preview mode for exploded images
Message-ID: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>

Allow exploded module readers created for exploded system images to support preview mode.

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

Commit messages:
 - Preview mode for exploded system module readers

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

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

From liach at openjdk.org  Wed Feb  4 15:28:56 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 15:28:56 GMT
Subject: [lworld] RFR: 8377162: [lworld] getResourceAsStream() doesn't work
 in preview mode for exploded images
In-Reply-To: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
References: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
Message-ID: <YzkGsFAK0r4nb5XSUKdOsEH95dtxqLcMhdQlPYMIBEU=.ef348544-60be-4f47-b9d1-c73e81ea06d8@github.com>

On Wed, 4 Feb 2026 13:07:53 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow exploded module readers created for exploded system images to support preview mode.

To merge into lworld, your issue title must start with a `[lworld]` prefix. So if this is intended for lworld only, rename the issue to `[lworld] getResourceAsStream() doesn't work in preview mode for exploded images`, or create a lworld subtask if the main issue is intended for mainline.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2032#issuecomment-3847592727

From duke at openjdk.org  Wed Feb  4 15:28:57 2026
From: duke at openjdk.org (David Beaumont)
Date: Wed, 4 Feb 2026 15:28:57 GMT
Subject: [lworld] RFR: 8377162: [lworld] getResourceAsStream() doesn't work
 in preview mode for exploded images
In-Reply-To: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
References: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
Message-ID: <cZqITGs65txJO5HKFDaoJb-fhVWbg-71WeEm-tcHjNM=.c2d7d105-545f-46d7-90e1-f403e982b833@github.com>

On Wed, 4 Feb 2026 13:07:53 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow exploded module readers created for exploded system images to support preview mode.

Oh dammit, thanks. I'd forgotten that. And since I cannot edit titles of PRs at the moment, I may have to just delete this and start again.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2032#issuecomment-3847924303

From liach at openjdk.org  Wed Feb  4 15:28:58 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 15:28:58 GMT
Subject: [lworld] RFR: 8377162: [lworld] getResourceAsStream() doesn't work
 in preview mode for exploded images
In-Reply-To: <cZqITGs65txJO5HKFDaoJb-fhVWbg-71WeEm-tcHjNM=.c2d7d105-545f-46d7-90e1-f403e982b833@github.com>
References: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
 <cZqITGs65txJO5HKFDaoJb-fhVWbg-71WeEm-tcHjNM=.c2d7d105-545f-46d7-90e1-f403e982b833@github.com>
Message-ID: <_0dYhPZDPGDxy47N2niW1Voi4ptvu9tBzVamBxPHkrs=.f8259205-bd9d-40bd-bcd5-ecfdcb5bbb3d@github.com>

On Wed, 4 Feb 2026 14:52:24 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allow exploded module readers created for exploded system images to support preview mode.
>
> Oh dammit, thanks. I'd forgotten that. And since I cannot edit titles of PRs at the moment, I may have to just delete this and start again.

@david-beaumont Try issue a command to skara:

> /issue JDK-8377162

The bot can help fix the title.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2032#issuecomment-3848025498

From jsikstro at openjdk.org  Wed Feb  4 15:30:47 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 4 Feb 2026 15:30:47 GMT
Subject: [lworld] RFR: 8376652: [lworld] Explicit and consistent names for
 nonstatic fields in FieldLayout [v4]
In-Reply-To: <1wMnNx9ZLWf-sgMtoQxJ2R-tIQTy1aH-kI-Lv7_o0Gc=.fd85524a-f087-4f7b-937a-a8bf97ea310b@github.com>
References: <jdG9_wKNaRaGyN0kgk7oUt3gN0LhOMXziM-qu9b_l5k=.23998916-c182-46e7-bfab-cc91ea8cbc1b@github.com>
 <dK3puls0Ta9D5OVMU-RdcDxSYFCJm7fIUvlH7tA2kD4=.caa3b0d7-d6e9-43ce-9669-78500fc2c89d@github.com>
 <1wMnNx9ZLWf-sgMtoQxJ2R-tIQTy1aH-kI-Lv7_o0Gc=.fd85524a-f087-4f7b-937a-a8bf97ea310b@github.com>
Message-ID: <T-ocTqIyV-D8veT-IQYnI3h-gQ0ut1aHiAzIFZF91u4=.53bb34d0-07a1-428e-94c0-0584e440e792@github.com>

On Fri, 30 Jan 2026 20:13:35 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renamed closest_non_static to closest_nonstatic
>
> Looks good to me.

Thank you for the reviews @fparain and @Arraying! I reran tier1-2 which is green.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1992#issuecomment-3848106268

From duke at openjdk.org  Wed Feb  4 15:30:49 2026
From: duke at openjdk.org (duke)
Date: Wed, 4 Feb 2026 15:30:49 GMT
Subject: [lworld] RFR: 8376652: [lworld] Explicit and consistent names for
 nonstatic fields in FieldLayout [v4]
In-Reply-To: <dK3puls0Ta9D5OVMU-RdcDxSYFCJm7fIUvlH7tA2kD4=.caa3b0d7-d6e9-43ce-9669-78500fc2c89d@github.com>
References: <jdG9_wKNaRaGyN0kgk7oUt3gN0LhOMXziM-qu9b_l5k=.23998916-c182-46e7-bfab-cc91ea8cbc1b@github.com>
 <dK3puls0Ta9D5OVMU-RdcDxSYFCJm7fIUvlH7tA2kD4=.caa3b0d7-d6e9-43ce-9669-78500fc2c89d@github.com>
Message-ID: <w_QpaxPgmbAa-AoB2X90N5SZQc-dc8vY7d0AtbwHnCU=.7ba5bf27-2deb-4356-b9b8-849548f036e6@github.com>

On Fri, 30 Jan 2026 08:23:13 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We should be explicit when naming variables that refer to "fields" and state whether we mean static or nonstatic fields.
>> 
>> I've also done a bit of cleanup in `FieldLayoutBuilder::compute_inline_class_layout()`, which calls `has_nonstatic_fields`. The "has_nonstatic_fields" property is inherited from the superklass whenever a klass instance is created, so we only have to check the property once on the "first" superklass.
>> 
>> Testing:
>> * Oracle's tier1-3, jdk_valhalla and hotspot_valhalla
>> * I added an assert to sanity test that the while loop I removed in `FieldLayoutBuilder::compute_inline_class_layout()` never gets past the "first" superklass, which didn't hit in tier1-3.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed closest_non_static to closest_nonstatic

@jsikstro 
Your change (at version 3da3c2db21127d26e125856faa7f7c6582dfa1a3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1992#issuecomment-3848115211

From duke at openjdk.org  Wed Feb  4 15:31:58 2026
From: duke at openjdk.org (David Beaumont)
Date: Wed, 4 Feb 2026 15:31:58 GMT
Subject: [lworld] RFR: 8377162: [lworld] getResourceAsStream() doesn't work
 in preview mode for exploded images
In-Reply-To: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
References: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
Message-ID: <Q8SdwcCgyoBX3GGRx23IKZHOlPp43bHIO0K3069fYmU=.f9abbac0-2903-402a-bae9-10a3ed54ed53@github.com>

On Wed, 4 Feb 2026 13:07:53 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow exploded module readers created for exploded system images to support preview mode.

For the record, GitHub's UI is busted right now. I didn't try the `/issue` thing (I didn't actually know about that) but the title could be changed via the github CLI tool (gh).

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

PR Comment: https://git.openjdk.org/valhalla/pull/2032#issuecomment-3848121593

From duke at openjdk.org  Wed Feb  4 15:38:07 2026
From: duke at openjdk.org (David Beaumont)
Date: Wed, 4 Feb 2026 15:38:07 GMT
Subject: [lworld] RFR: 8377162: [lworld] getResourceAsStream() doesn't work
 in preview mode for exploded images
In-Reply-To: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
References: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
Message-ID: <XQ-f5tojBayzpCrbL-2Wrgn7i-bBwjvJas2tYwHjI1M=.3314c961-599c-4ee4-a35b-613d615c3000@github.com>

On Wed, 4 Feb 2026 13:07:53 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow exploded module readers created for exploded system images to support preview mode.

I'll set this back to draft for now since I need to add proper unit tests for this.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2032#issuecomment-3848157868

From forax at univ-mlv.fr  Wed Feb  4 15:43:00 2026
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 4 Feb 2026 16:43:00 +0100 (CET)
Subject: bworld - java laucher vs restricted field
Message-ID: <436539784.33563348.1770219780179.JavaMail.zimbra@univ-eiffel.fr>

Hello,
I'm testing the restricted fields on the bworld branch,
running the source code directly with the command "java" without using javac failed.

step to reproduce:

$JAVA_HOME/bin/java --enable-preview ComplexBox.java

ComplexBox.java:10: error: cannot access NullRestricted
public class ComplexBox {
       ^
  class file for jdk.internal.vm.annotation.NullRestricted not found
1 error
error: compilation failed

If instead, I first compile and then run, there is no issue.

---
public class ComplexBox {
  public value record Complex(int re, int im) {}

  private Complex! complex;

  public ComplexBox(Complex! complex) {
    this.complex = complex;
    super();
  }

  @Override
  public String toString() {
    return "ComplexBox (" + complex + ")";
  }

  // -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlineLayout
  static void main() {
    var complex = new Complex(2, 1);
    var box = new ComplexBox(complex);

    IO.println(box);
  }
}

From chagedorn at openjdk.org  Wed Feb  4 15:44:59 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 4 Feb 2026 15:44:59 GMT
Subject: [lworld] RFR: 8376733: [lworld] Inconsistent result of
 Invoke::declared_type triggers assert in profiling
In-Reply-To: <TzLN7lPwoJDBMkyY5sCY2oH7mVnS7Oyx9OGpB3lL-84=.367f6412-6b0a-4252-af1f-43e8e00ee8ce@github.com>
References: <TzLN7lPwoJDBMkyY5sCY2oH7mVnS7Oyx9OGpB3lL-84=.367f6412-6b0a-4252-af1f-43e8e00ee8ce@github.com>
Message-ID: <ay39ra-VMn1jWAnILBQQqMMoT9Y88U9yHdt-4p7tW9k=.c0f774bf-833b-4ba9-8815-028c13c1b68d@github.com>

On Wed, 4 Feb 2026 12:47:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Old mainline fix [JDK-8134389](https://bugs.openjdk.org/browse/JDK-8134389) modified code in `Invoke::declared_type` to not use the return type of the target signature but use the declared signature instead (see [changeset](https://hg.openjdk.org/jdk9/jdk9/hotspot/rev/4191b33b3629) for details). This was needed for method handle call sites to return `java/lang/invoke/CallSite` instead of `java/lang/Object` or whatever the target method return type would look like. The test `compiler/jsr292/TestArrayReturnType.java` still reliably triggers this scenario.
> 
> Now the problem is that the return type is re-computed on every call to `Invoke::declared_type` but it might actually change from unloaded to loaded in-between and therefore different `ciType` objects will be returned. In the failing case, the return type first is
> `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=false ident=1498 address=0x00007ae57d775728>` 
> and later it's `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=true ident=1508 address=0x00007ae57d7762a8>` (note the different `loaded` property). This leads to an assertion failure in profiling because we invoke CHA to improve a type that's already final because when we checked the type earlier, it was still unloaded.
> 
> I think it's a general rule that the compiler interface needs to guarantee consistency of types during compilation and therefore I adjusted the code to only compute the return type once. This is a mainline issue and could be fixed in mainline as well. However, as far as I can tell, only Valhalla is currently affected because the Valhalla specific array load/store profiling uses `LIRGenerator::profile_type` in more cases. Let's therefore only fix it in Valhalla for now.
> 
> Thanks,
> Tobias

That looks good to me.

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2031#pullrequestreview-3751797422

From thartmann at openjdk.org  Wed Feb  4 15:45:00 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 4 Feb 2026 15:45:00 GMT
Subject: [lworld] RFR: 8376733: [lworld] Inconsistent result of
 Invoke::declared_type triggers assert in profiling
In-Reply-To: <TzLN7lPwoJDBMkyY5sCY2oH7mVnS7Oyx9OGpB3lL-84=.367f6412-6b0a-4252-af1f-43e8e00ee8ce@github.com>
References: <TzLN7lPwoJDBMkyY5sCY2oH7mVnS7Oyx9OGpB3lL-84=.367f6412-6b0a-4252-af1f-43e8e00ee8ce@github.com>
Message-ID: <6wWgNHz0EwyU9w6uLqUGUPv4uTNrrxB4ipXmEI-MBmg=.56701677-7f15-4af6-9b75-c688965f56d3@github.com>

On Wed, 4 Feb 2026 12:47:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Old mainline fix [JDK-8134389](https://bugs.openjdk.org/browse/JDK-8134389) modified code in `Invoke::declared_type` to not use the return type of the target signature but use the declared signature instead (see [changeset](https://hg.openjdk.org/jdk9/jdk9/hotspot/rev/4191b33b3629) for details). This was needed for method handle call sites to return `java/lang/invoke/CallSite` instead of `java/lang/Object` or whatever the target method return type would look like. The test `compiler/jsr292/TestArrayReturnType.java` still reliably triggers this scenario.
> 
> Now the problem is that the return type is re-computed on every call to `Invoke::declared_type` but it might actually change from unloaded to loaded in-between and therefore different `ciType` objects will be returned. In the failing case, the return type first is
> `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=false ident=1498 address=0x00007ae57d775728>` 
> and later it's `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=true ident=1508 address=0x00007ae57d7762a8>` (note the different `loaded` property). This leads to an assertion failure in profiling because we invoke CHA to improve a type that's already final because when we checked the type earlier, it was still unloaded.
> 
> I think it's a general rule that the compiler interface needs to guarantee consistency of types during compilation and therefore I adjusted the code to only compute the return type once. This is a mainline issue and could be fixed in mainline as well. However, as far as I can tell, only Valhalla is currently affected because the Valhalla specific array load/store profiling uses `LIRGenerator::profile_type` in more cases. Let's therefore only fix it in Valhalla for now.
> 
> Thanks,
> Tobias

Thanks for the review Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2031#issuecomment-3848198664

From alanb at openjdk.org  Wed Feb  4 15:48:35 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Feb 2026 15:48:35 GMT
Subject: [lworld] RFR: 8377162: [lworld] getResourceAsStream() doesn't work
 in preview mode for exploded images
In-Reply-To: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
References: <OlQmFPlU_rNZp_cQHpnB_rU508jghSk9pJSuXnd0YSo=.3c790573-98cb-4080-9189-c0d1c0813d06@github.com>
Message-ID: <bZ3vGRM9-Mx134ecsIUS3VEdq266MY9EU-neMkPybiA=.f9f628aa-0ad9-44b8-9e2d-5e978ff278c4@github.com>

On Wed, 4 Feb 2026 13:07:53 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow exploded module readers created for exploded system images to support preview mode.

src/java.base/share/classes/jdk/internal/module/ModulePath.java line 123:

> 121:      * packaged modules. The modules may be patched by the given ModulePatcher.
> 122:      *
> 123:      * <p>This method is deliberately package visible to restrict any use of the

I think it would be better to drop the "is  deliberately package visible" comment. The reason the other factory methods are public is that they are accessed from code in other packages.

src/java.base/share/classes/jdk/internal/module/ModulePath.java line 126:

> 124:      * preview mode flag to system modules only.
> 125:      */
> 126:     static ModuleFinder ofSystem(ModulePatcher patcher, boolean previewMode, Path moduleDir) {

I'd prefer name it "of" to be the same as other factory methods.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2032#discussion_r2764558915
PR Review Comment: https://git.openjdk.org/valhalla/pull/2032#discussion_r2764568854

From vromero at openjdk.org  Wed Feb  4 15:56:48 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 15:56:48 GMT
Subject: [lworld] RFR: 8373916: [lworld] TypeName.this.FieldName should be
 restricted in early construction context [v2]
In-Reply-To: <YAHcwb3fH5lq04HyJNCSvyikXq4ln6AYNuXCAyhoTEE=.dc0fd584-ff82-4a28-bd3f-5eae478b2b31@github.com>
References: <PFIV5VMh3yr89nSroOnlExmiW_vaEtGooltfIXeUMJM=.9b82025e-99ec-430a-b40d-f2681d9a6437@github.com>
 <rEBhaTceHdd-z8YdFJ6-Vvse83y-0oPbe5ueNMERgKY=.65f34f31-20aa-4eef-9763-0635d0469cf3@github.com>
 <YAHcwb3fH5lq04HyJNCSvyikXq4ln6AYNuXCAyhoTEE=.dc0fd584-ff82-4a28-bd3f-5eae478b2b31@github.com>
Message-ID: <Wssxgm_cLbrCp8hCxkFyXPn-Ossx0WRAuTaio3SGOIs=.0735943a-dbfa-4390-86a8-829fbc9b88aa@github.com>

On Tue, 3 Feb 2026 18:30:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero 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:
>> 
>>  - adding test case
>>  - Merge branch 'lworld' into JDK-8373916
>>  - 8373916: [lworld] TypeName.this.FieldName should be restricted in early construction context
>
> Looks good

@mcimadamore thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1899#issuecomment-3848248998

From vromero at openjdk.org  Wed Feb  4 15:56:49 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 15:56:49 GMT
Subject: [lworld] Integrated: 8373916: [lworld] TypeName.this.FieldName should
 be restricted in early construction context
In-Reply-To: <PFIV5VMh3yr89nSroOnlExmiW_vaEtGooltfIXeUMJM=.9b82025e-99ec-430a-b40d-f2681d9a6437@github.com>
References: <PFIV5VMh3yr89nSroOnlExmiW_vaEtGooltfIXeUMJM=.9b82025e-99ec-430a-b40d-f2681d9a6437@github.com>
Message-ID: <ZIkmb2YpbTPLiYSvrQY6_5wSIEW6bILrK8gI48lCmW4=.fbe63d94-de0e-4e81-ad09-e862fd5a221d@github.com>

On Tue, 13 Jan 2026 20:28:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> According to spec bugs: JDK-8373719 and JDK-8373721:
> 
> In JLS 6.5.6.1, references to fields are subject to a handful of restrictions if they refer to instance fields. In 15.8 and 15.11, 'this.x' and 'super.x' are intended to be viewed as instance field references, and subject to the same restrictions.
> 
> So the following code should fail to compile:
> 
> class Test {
>     static final boolean check = true;
>     Test(int a) {
>         boolean b = Test.this.check; //compilation error expected here
>         this();
>     }
> }
> 
> However, javac is currently accepting it

This pull request has now been integrated.

Changeset: 7aa4941a
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7aa4941a62f7af036b9ea562b928490f0271d64c
Stats:     47 lines in 6 files changed: 44 ins; 0 del; 3 mod

8373916: [lworld] TypeName.this.FieldName should be restricted in early construction context

Reviewed-by: liach, mcimadamore

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

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

From liach at openjdk.org  Wed Feb  4 16:01:10 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 16:01:10 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer
In-Reply-To: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
Message-ID: <qXHGAhl1mjSjPv93eA96dIfZc4yAs2uFrgBtvMb9ao0=.ef88780c-7fde-4f16-b72d-7a2b715a4abc@github.com>

On Mon, 2 Feb 2026 23:34:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...

After discusssion, I think the current removal should be ok - only offering the replacmenet functionality when UseArrayFlattening is enabled is acceptable for JEP 401.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3848287252

From qamai at openjdk.org  Wed Feb  4 16:01:43 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 16:01:43 GMT
Subject: [lworld] RFR: 8376213: [lworld] C2: assert(is_InlineType()) failed:
 invalid node class: Phi/LoadP/DecodeN
Message-ID: <UwwpAqM5PVMCyjFvkQxrHDEIMwYhZLHwgVseNuM2-I8=.646b6f7d-2abe-4d61-bc01-28609a64dcc7@github.com>

Hi,

The issue here is that not all fields of inline types are expanded to `InlineTypeNode`s. The decision to expand them should have been done when we obtain the object, so we just need to check if the field value is a `InlineTypeNode` here.

Testing:

- [ ] tier1-4,valhalla-comp-stress, Linux-x64

Please kindly review, thanks a lot.

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

Commit messages:
 - Acmp does not work with cyclic value classes

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

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

From frederic.parain at oracle.com  Wed Feb  4 16:28:40 2026
From: frederic.parain at oracle.com (Frederic Parain)
Date: Wed, 4 Feb 2026 11:28:40 -0500
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_Valhalla_Committer=3A_Joel_Sikstr=C3=B6m?=
In-Reply-To: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
References: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
Message-ID: <e6b21d4d-3ecb-4df6-973c-c9e179ff4f29@oracle.com>

Vote: yes

Fred

On 2/4/26 09:09, David Simms wrote:
> |I hereby nominate Joel Sikstr?m to Valhalla Committer. Joel is an 
> OpenJDK reviewer with over 50 contributions [1]. Votes are due by 18th 
> of February 2026, 14:00z. Only current Valhalla Committers [2] are 
> eligible to vote on this nomination. Votes must be cast in the open by 
> replying to this mailing list. For Lazy Consensus voting instructions, 
> see [3]. David Simms [1] 
> https://github.com/search?q=committer-name%3A%22Joel+Sikstr%C3%B6m%22+repo%3Aopenjdk%2Fjdk&type=commits 
> [2] https://openjdk.org/census [3] 
> https://openjdk.org/projects/#committer-vote|
>
>

From liach at openjdk.org  Wed Feb  4 16:46:27 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 16:46:27 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest
Message-ID: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>

When we read a class file and decode the access flag, we should use the class file's version to decode the flag, so we won't get spurious SUPER and IDENTITY mismatches.

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

Commit messages:
 - 8366270

Changes: https://git.openjdk.org/valhalla/pull/2036/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2036&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366270
  Stats: 44 lines in 6 files changed: 28 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/valhalla/pull/2036.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2036/head:pull/2036

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

From dlsmith at openjdk.org  Wed Feb  4 16:49:35 2026
From: dlsmith at openjdk.org (Dan Smith)
Date: Wed, 4 Feb 2026 16:49:35 GMT
Subject: RFR: Support preview features in libraries
Message-ID: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>

Always allow preview class files, compile standard libs with --enable-preview

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

Commit messages:
 - Always allow preview class files, compile standard libs with --enable-preview

Changes: https://git.openjdk.org/valhalla/pull/2037/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2037&range=00
  Stats: 17 lines in 7 files changed: 5 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/valhalla/pull/2037.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2037/head:pull/2037

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

From liach at openjdk.org  Wed Feb  4 16:51:50 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 16:51:50 GMT
Subject: [lworld] RFR: 8376652: [lworld] Explicit and consistent names for
 nonstatic fields in FieldLayout [v4]
In-Reply-To: <dK3puls0Ta9D5OVMU-RdcDxSYFCJm7fIUvlH7tA2kD4=.caa3b0d7-d6e9-43ce-9669-78500fc2c89d@github.com>
References: <jdG9_wKNaRaGyN0kgk7oUt3gN0LhOMXziM-qu9b_l5k=.23998916-c182-46e7-bfab-cc91ea8cbc1b@github.com>
 <dK3puls0Ta9D5OVMU-RdcDxSYFCJm7fIUvlH7tA2kD4=.caa3b0d7-d6e9-43ce-9669-78500fc2c89d@github.com>
Message-ID: <r2vfEKmOuo7n_YSoQU-9x7NUu2BeMQG9U5bA5YI72mI=.42408dc2-432f-44ba-8a2c-601d5b2a513e@github.com>

On Fri, 30 Jan 2026 08:23:13 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We should be explicit when naming variables that refer to "fields" and state whether we mean static or nonstatic fields.
>> 
>> I've also done a bit of cleanup in `FieldLayoutBuilder::compute_inline_class_layout()`, which calls `has_nonstatic_fields`. The "has_nonstatic_fields" property is inherited from the superklass whenever a klass instance is created, so we only have to check the property once on the "first" superklass.
>> 
>> Testing:
>> * Oracle's tier1-3, jdk_valhalla and hotspot_valhalla
>> * I added an assert to sanity test that the while loop I removed in `FieldLayoutBuilder::compute_inline_class_layout()` never gets past the "first" superklass, which didn't hit in tier1-3.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed closest_non_static to closest_nonstatic

Thanks for this fix!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1992#issuecomment-3848555362

From jsikstro at openjdk.org  Wed Feb  4 16:51:51 2026
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 4 Feb 2026 16:51:51 GMT
Subject: [lworld] Integrated: 8376652: [lworld] Explicit and consistent names
 for nonstatic fields in FieldLayout
In-Reply-To: <jdG9_wKNaRaGyN0kgk7oUt3gN0LhOMXziM-qu9b_l5k=.23998916-c182-46e7-bfab-cc91ea8cbc1b@github.com>
References: <jdG9_wKNaRaGyN0kgk7oUt3gN0LhOMXziM-qu9b_l5k=.23998916-c182-46e7-bfab-cc91ea8cbc1b@github.com>
Message-ID: <-RjQOYXifpmJbK4EGbcmaXncCFNTtYqGvTLTP5oFA-g=.dee4a302-475c-4985-8eb9-3adc5e403251@github.com>

On Thu, 29 Jan 2026 08:04:19 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> We should be explicit when naming variables that refer to "fields" and state whether we mean static or nonstatic fields.
> 
> I've also done a bit of cleanup in `FieldLayoutBuilder::compute_inline_class_layout()`, which calls `has_nonstatic_fields`. The "has_nonstatic_fields" property is inherited from the superklass whenever a klass instance is created, so we only have to check the property once on the "first" superklass.
> 
> Testing:
> * Oracle's tier1-3, jdk_valhalla and hotspot_valhalla
> * I added an assert to sanity test that the while loop I removed in `FieldLayoutBuilder::compute_inline_class_layout()` never gets past the "first" superklass, which didn't hit in tier1-3.

This pull request has now been integrated.

Changeset: 8b04a6e3
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8b04a6e3d92fd0b39e49456824d877dae8df9534
Stats:     36 lines in 4 files changed: 2 ins; 13 del; 21 mod

8376652: [lworld] Explicit and consistent names for nonstatic fields in FieldLayout

Reviewed-by: fparain, phubner

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

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

From liach at openjdk.org  Wed Feb  4 16:58:49 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 16:58:49 GMT
Subject: RFR: Support preview features in libraries
In-Reply-To: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
References: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
Message-ID: <qUa3QTrSNpbq4tOD2a1SkA1STuW1MbOaMRcdNQG-nVI=.e5c3a60c-392c-42c2-a9fb-521e8462f371@github.com>

On Wed, 4 Feb 2026 16:44:19 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Always allow preview class files, compile standard libs with --enable-preview

src/jdk.jpackage/share/classes/jdk/jpackage/internal/CfgFile.java line 132:

> 130:             this.appModsDirectory = appModsDirectory;
> 131:             super();
> 132:             if (!appModsDirectory.startsWith(appDirectory())) {

Let's make `appDirectory` static instead.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2037#discussion_r2764997752

From matsaave at openjdk.org  Wed Feb  4 17:36:23 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 4 Feb 2026 17:36:23 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v2]
In-Reply-To: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
Message-ID: <5qLNjU_1skgG_vvIVZFECvaN5uWXsC8nA_2TIX_WfOE=.b6b7e6b3-831d-40f3-a0a1-7bba4e30cbe4@github.com>

> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Remove strict_init from Modifier

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2025/files
  - new: https://git.openjdk.org/valhalla/pull/2025/files/77e04d1f..b2c024b1

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

  Stats: 22 lines in 2 files changed: 1 ins; 19 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/2025.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2025/head:pull/2025

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

From qamai at openjdk.org  Wed Feb  4 17:36:53 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 17:36:53 GMT
Subject: [lworld] RFR: 8377171: [lworld] Comment warnings for internal
 valhalla annotations
In-Reply-To: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
References: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
Message-ID: <mTXO-9Jsm6p_qkNdYCD91ZuYdk_RuGPbdvaPwns57OM=.6abe1a45-8009-4418-a565-929fbbca133c@github.com>

On Tue, 3 Feb 2026 15:20:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Add some warning comments for value-related annotations in jdk.internal, to discourage their misuse.

I think there is no need to discourage usages of these annotations more than the fact that they are internal APIs. Furthermore, it is also really helpful when people use them experimentally, which can help us uncover implementation issues with these configurations.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2023#issuecomment-3848779660

From liach at openjdk.org  Wed Feb  4 17:36:53 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 17:36:53 GMT
Subject: [lworld] RFR: 8377171: [lworld] Comment warnings for internal
 valhalla annotations
In-Reply-To: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
References: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
Message-ID: <mKt6mDIBTy8gBwL8D6GZZe3xKQWcBpO2dZ4iWBZ1Urs=.c4591a39-dcca-4579-ad09-2863b5c3c2f9@github.com>

On Tue, 3 Feb 2026 15:20:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Add some warning comments for value-related annotations in jdk.internal, to discourage their misuse.

These annotations only promise the performance features from the JVM and has nothing to do with the future language semantics proposed by project Valhalla. I think the warnings I added are adequate about how they are not going to correspond to future Java language features.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2023#issuecomment-3848793733

From vromero at openjdk.org  Wed Feb  4 17:49:59 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 17:49:59 GMT
Subject: RFR: Support preview features in libraries
In-Reply-To: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
References: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
Message-ID: <ln82ZCDejHi5HiO-DswYggf8k6VZ_6Q4utTgWNA-Plk=.e0719eec-b54b-4c68-9ac7-407b43014f68@github.com>

On Wed, 4 Feb 2026 16:44:19 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Always allow preview class files, compile standard libs with --enable-preview

suggestion for all langtools tests to pass:


diff --git a/test/langtools/tools/javac/diags/examples.not-yet.txt b/test/langtools/tools/javac/diags/examples.not-yet.txt
index a1a56c3d445..254659d4f59 100644
--- a/test/langtools/tools/javac/diags/examples.not-yet.txt
+++ b/test/langtools/tools/javac/diags/examples.not-yet.txt
@@ -233,3 +233,6 @@ compiler.misc.attribute.not.applicable.to.field.type                     # bad c
 compiler.misc.attribute.only.applicable.to.fields                        # bad class file
 compiler.warn.suspicious.nullness.conversion
 compiler.err.restricted.array.missing.init
+
+#temporary bworld-apis
+compiler.warn.preview.feature.use.classfile
\ No newline at end of file
diff --git a/test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java b/test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java
index 2b953084f3d..15577e7c6c8 100644
--- a/test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java
+++ b/test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java
@@ -24,7 +24,6 @@
 // key: compiler.misc.feature.primitive.patterns
 // key: compiler.warn.preview.feature.use.plural
 // as of Valhalla, j.l.Record is a preview class:
-// key: compiler.warn.preview.feature.use.classfile
 // options: --enable-preview -source ${jdk.version} -Xlint:preview
 
 class PrimitivePatternMatching {
diff --git a/test/langtools/tools/javac/preview/classReaderTest/Client.java b/test/langtools/tools/javac/preview/classReaderTest/Client.java
index 74bb99327d6..a9ac174f840 100644
--- a/test/langtools/tools/javac/preview/classReaderTest/Client.java
+++ b/test/langtools/tools/javac/preview/classReaderTest/Client.java
@@ -3,8 +3,6 @@
  * @bug 8199194
  * @summary smoke test for --enabled-preview classreader support
  * @compile -XDforcePreview --enable-preview -source ${jdk.version} Bar.java
- * @compile/fail/ref=Client.nopreview.out -Xlint:preview -XDrawDiagnostics Client.java
- * @compile/fail/ref=Client.preview.out -Werror -Xlint:preview -XDrawDiagnostics --enable-preview -source ${jdk.version} Client.java
  */
 
 public class Client {

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

PR Comment: https://git.openjdk.org/valhalla/pull/2037#issuecomment-3848860358

From qamai at openjdk.org  Wed Feb  4 18:01:43 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 18:01:43 GMT
Subject: [lworld] RFR: 8377171: [lworld] Comment warnings for internal
 valhalla annotations
In-Reply-To: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
References: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
Message-ID: <_pfY55a0EXxdr9cFe0BJmoT7fPwX7O-0VpUEdGtthlk=.6b0221d5-5aa8-4e91-88ad-61c7a99e95dc@github.com>

On Tue, 3 Feb 2026 15:20:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Add some warning comments for value-related annotations in jdk.internal, to discourage their misuse.

Your reasoning implies that internal annotations somehow often corresponds to future language semantics, which is not the case.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2023#issuecomment-3848911999

From vromero at openjdk.org  Wed Feb  4 18:22:48 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 18:22:48 GMT
Subject: RFR: Merge lworld
Message-ID: <p5nFsr1sy81RkU_nMhARCeZUntsTnWloCFEU6Ngid68=.a0d9e83b-c518-493e-acb0-19aefa76807e@github.com>

Merge branch 'lworld' into bworld_merge_lworld

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

Commit messages:
 - Merge branch 'lworld' into bworld_merge_lworld
 - 8376652: [lworld] Explicit and consistent names for nonstatic fields in FieldLayout
 - 8373916: [lworld] TypeName.this.FieldName should be restricted in early construction context
 - 8376791: [lworld] C2 compilation hits assert(!not_flat || !is_flat()) failed: inconsistency
 - 8376813: [lworld] Add print for dummy field reused as null-marker

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

Changes: https://git.openjdk.org/valhalla/pull/2038/files
  Stats: 147 lines in 12 files changed: 88 ins; 13 del; 46 mod
  Patch: https://git.openjdk.org/valhalla/pull/2038.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2038/head:pull/2038

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

From darcy at openjdk.org  Wed Feb  4 18:34:12 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Feb 2026 18:34:12 GMT
Subject: RFR: [type-classes] 8377123: Add SIZE and BYTES static fields to
 UnsignedInt
In-Reply-To: <XaURbxP3kWM_-e-homSYgTC1kknqumdR7AMJORbkO9M=.c789ba35-fb5d-4ea7-814d-a5f77f374532@github.com>
References: <Y3wToYG3mIX6NdR1OHCFNMcJ4p8PFd9xRNz8mnfyrWM=.4ee23942-8572-44d0-99c7-8fd04e0d5e20@github.com>
 <XaURbxP3kWM_-e-homSYgTC1kknqumdR7AMJORbkO9M=.c789ba35-fb5d-4ea7-814d-a5f77f374532@github.com>
Message-ID: <4BY0tNhBSHzxXmNKytwjDyYQdlQ4WT1Zo2pIE3r1NCw=.28040b99-494c-4f69-93b8-6cb4530d6c80@github.com>

On Wed, 4 Feb 2026 09:54:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks good -- not sure if we should mention the word "flat" anywhere (e.g. in the field name, or in the javadoc) -- after all, an UnsignedInt instance is 4 bytes only when flattened and null-restricted. Maybe MIN_SIZE/MIN_BYTES :-)
> 
> We can also settle on the name later...

I'll push it as-as and we can refine the wording/naming later; thanks.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2028#issuecomment-3849067903

From darcy at openjdk.org  Wed Feb  4 18:34:13 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Feb 2026 18:34:13 GMT
Subject: Integrated: [type-classes] 8377123: Add SIZE and BYTES static fields
 to UnsignedInt
In-Reply-To: <Y3wToYG3mIX6NdR1OHCFNMcJ4p8PFd9xRNz8mnfyrWM=.4ee23942-8572-44d0-99c7-8fd04e0d5e20@github.com>
References: <Y3wToYG3mIX6NdR1OHCFNMcJ4p8PFd9xRNz8mnfyrWM=.4ee23942-8572-44d0-99c7-8fd04e0d5e20@github.com>
Message-ID: <Jvaez3MgztNMYP9GUR0E5Z0U02AeqeHzRjggm15c7KY=.6586fd53-ce53-4e96-afad-d333700c60c9@github.com>

On Tue, 3 Feb 2026 23:23:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add SIZE and BYTES fields to UnsignedInt, analagous to those fields from java.lang.Integer.

This pull request has now been integrated.

Changeset: 7ccc7603
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7ccc7603a8559025891e8ac48f79c409f465bab9
Stats:     12 lines in 1 file changed: 0 ins; 1 del; 11 mod

[type-classes] 8377123: Add SIZE and BYTES static fields to UnsignedInt

Reviewed-by: mcimadamore

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

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

From serguei.spitsyn at oracle.com  Wed Feb  4 18:39:05 2026
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Wed, 4 Feb 2026 18:39:05 +0000
Subject: =?iso-8859-1?Q?Re:_CFV:_New_Valhalla_Committer:_Joel_Sikstr=F6m?=
In-Reply-To: <e6b21d4d-3ecb-4df6-973c-c9e179ff4f29@oracle.com>
References: <615d7758-4598-49e1-bfc8-6fd94cdda88b@oracle.com>
 <e6b21d4d-3ecb-4df6-973c-c9e179ff4f29@oracle.com>
Message-ID: <IA1PR10MB66877F1DB7189B823840181C8D98A@IA1PR10MB6687.namprd10.prod.outlook.com>

Vote: yes



Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20260204/0bbbd428/attachment.htm>

From vromero at openjdk.org  Wed Feb  4 18:44:29 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 18:44:29 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <p5nFsr1sy81RkU_nMhARCeZUntsTnWloCFEU6Ngid68=.a0d9e83b-c518-493e-acb0-19aefa76807e@github.com>
References: <p5nFsr1sy81RkU_nMhARCeZUntsTnWloCFEU6Ngid68=.a0d9e83b-c518-493e-acb0-19aefa76807e@github.com>
Message-ID: <r4LL4kImh3GJltv9odPSmbAkQyoBEUMD-DKF0Ca9SMQ=.87de7fa3-030e-4c73-adbc-8f00e69629bc@github.com>

> Merge branch 'lworld' into bworld_merge_lworld

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits:

 - Merge branch 'lworld' into bworld_merge_lworld
 - Merge lworld
 - Remove redundant null checks
   
   Reviewed-by: mcimadamore
 - add javac and javap support for the ACC_NULL_CHECKED flag
   
   Reviewed-by: liach
 - Merge lworld
 - javac should not place initializers of null restricted fields before the super invocation
   
   Reviewed-by: liach
 - Merge lworld
 - fixing bug in null checks generation
   
   Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
   Reviewed-by: jlahoda
 - Removing commented tests
 - Merge lworld
 - ... and 115 more: https://git.openjdk.org/valhalla/compare/8b04a6e3...ba674eed

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

Changes: https://git.openjdk.org/valhalla/pull/2038/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2038&range=01
  Stats: 8110 lines in 116 files changed: 7778 ins; 64 del; 268 mod
  Patch: https://git.openjdk.org/valhalla/pull/2038.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2038/head:pull/2038

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

From vromero at openjdk.org  Wed Feb  4 18:44:32 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 18:44:32 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <p5nFsr1sy81RkU_nMhARCeZUntsTnWloCFEU6Ngid68=.a0d9e83b-c518-493e-acb0-19aefa76807e@github.com>
References: <p5nFsr1sy81RkU_nMhARCeZUntsTnWloCFEU6Ngid68=.a0d9e83b-c518-493e-acb0-19aefa76807e@github.com>
Message-ID: <CbzLkEC6Vvci4z_P0SkcVf5ulVYxRd3QfaAy0IfYlag=.cacc49e0-6189-4bf5-9352-db6ce5e911ae@github.com>

On Wed, 4 Feb 2026 18:16:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into bworld_merge_lworld

This pull request has now been integrated.

Changeset: 5fecff01
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5fecff01a0891edb5a2faaffefc0e02e9fa45c5f
Stats:     147 lines in 12 files changed: 88 ins; 13 del; 46 mod

Merge lworld

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

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

From fparain at openjdk.org  Wed Feb  4 18:47:24 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 4 Feb 2026 18:47:24 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v2]
In-Reply-To: <5qLNjU_1skgG_vvIVZFECvaN5uWXsC8nA_2TIX_WfOE=.b6b7e6b3-831d-40f3-a0a1-7bba4e30cbe4@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <5qLNjU_1skgG_vvIVZFECvaN5uWXsC8nA_2TIX_WfOE=.b6b7e6b3-831d-40f3-a0a1-7bba4e30cbe4@github.com>
Message-ID: <brBJ_sLD-c-1lyUBVqDfXQiyysXe5HE-vWC5CQ-s89Q=.8d70b8f3-5388-459e-a4cd-dd214746ee1f@github.com>

On Wed, 4 Feb 2026 17:36:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove strict_init from Modifier

JVM changes look good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2025#pullrequestreview-3752752686

From fparain at openjdk.org  Wed Feb  4 18:52:50 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 4 Feb 2026 18:52:50 GMT
Subject: [lworld] RFR: 8377171: [lworld] Comment warnings for internal
 valhalla annotations
In-Reply-To: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
References: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
Message-ID: <tqtoKd3kY_hgPMgaRQca4paUb7eVI4EcrTGAwP-PVAc=.10d2a574-1cfc-4668-abcc-ce998221b149@github.com>

On Tue, 3 Feb 2026 15:20:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Add some warning comments for value-related annotations in jdk.internal, to discourage their misuse.

src/java.base/share/classes/jdk/internal/vm/annotation/LooselyConsistentValue.java line 52:

> 50:  * <p>
> 51:  * This annotation is only recognized on classes from the boot and platform
> 52:  * class loaders and is ignored elsewhere.

There's no such restriction in the current implementation.

src/java.base/share/classes/jdk/internal/vm/annotation/NullRestricted.java line 53:

> 51:  * <p>
> 52:  * This annotation is only recognized on classes from the boot and platform
> 53:  * class loaders and is ignored elsewhere.

There's no such restriction in the current implementation.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2023#discussion_r2765506920
PR Review Comment: https://git.openjdk.org/valhalla/pull/2023#discussion_r2765507477

From liach at openjdk.org  Wed Feb  4 19:01:37 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 19:01:37 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest [v2]
In-Reply-To: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>
References: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>
Message-ID: <pdYB9t2zlDFHNONan1ugVNPDxb56nFMt9qN3CNcHbOw=.d7c31bbb-f701-438c-91db-766888db54fa@github.com>

> When we read a class file and decode the access flag, we should use the class file's version to decode the flag, so we won't get spurious SUPER and IDENTITY mismatches.

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

 - Fix version parse bug, improve coverage
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/accessflags-pass-cffv
 - 8366270

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2036/files
  - new: https://git.openjdk.org/valhalla/pull/2036/files/c3f92ae3..b4cfe1e4

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

  Stats: 104 lines in 6 files changed: 37 ins; 15 del; 52 mod
  Patch: https://git.openjdk.org/valhalla/pull/2036.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2036/head:pull/2036

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

From liach at openjdk.org  Wed Feb  4 19:04:51 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 19:04:51 GMT
Subject: [lworld] RFR: 8377171: [lworld] Comment warnings for internal
 valhalla annotations [v2]
In-Reply-To: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
References: <ebdvh9etym6R-N7Rg5nJenoEG6qKsr7vmcAGiAO7W_c=.e8944d1d-fcac-4066-a9c0-cc8f805e1fd5@github.com>
Message-ID: <U9P5HyUKgjsltMeqt079TJle6Zq6QJNX8W4h2W57lfE=.f64a2146-ea61-4e0b-be42-8ad04f828ef0@github.com>

> Add some warning comments for value-related annotations in jdk.internal, to discourage their misuse.

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

 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into doc/value-annos-risk
 - Incorrect statements
 - Warnings for value annotations

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2023/files
  - new: https://git.openjdk.org/valhalla/pull/2023/files/c710005d..6a3ed516

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

  Stats: 15528 lines in 412 files changed: 8486 ins; 3771 del; 3271 mod
  Patch: https://git.openjdk.org/valhalla/pull/2023.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2023/head:pull/2023

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

From liach at openjdk.org  Wed Feb  4 19:12:21 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 19:12:21 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v2]
In-Reply-To: <5qLNjU_1skgG_vvIVZFECvaN5uWXsC8nA_2TIX_WfOE=.b6b7e6b3-831d-40f3-a0a1-7bba4e30cbe4@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <5qLNjU_1skgG_vvIVZFECvaN5uWXsC8nA_2TIX_WfOE=.b6b7e6b3-831d-40f3-a0a1-7bba4e30cbe4@github.com>
Message-ID: <jvZrgkCYebQQZtnZPh7L8yfZhPPOTdEKt-qKrnahKIY=.273aeb3d-1339-4f27-920f-dcb37be0d254@github.com>

On Wed, 4 Feb 2026 17:36:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove strict_init from Modifier

You can consider updating the copyright on the changed files.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2025#pullrequestreview-3752875441

From jan.lahoda at oracle.com  Wed Feb  4 19:32:19 2026
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 4 Feb 2026 20:32:19 +0100
Subject: bworld - java laucher vs restricted field
In-Reply-To: <436539784.33563348.1770219780179.JavaMail.zimbra@univ-eiffel.fr>
References: <436539784.33563348.1770219780179.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <18742a4c-dae1-4e95-ae18-d3ccf5b1f5d5@oracle.com>

Hi Remi,


Thanks for the report. Please see for what I think is the cause and a 
possible fix:
https://github.com/openjdk/valhalla/pull/2039


Jan


On 2/4/26 16:43, Remi Forax wrote:
> Hello,
> I'm testing the restricted fields on the bworld branch,
> running the source code directly with the command "java" without using javac failed.
>
> step to reproduce:
>
> $JAVA_HOME/bin/java --enable-preview ComplexBox.java
>
> ComplexBox.java:10: error: cannot access NullRestricted
> public class ComplexBox {
>         ^
>    class file for jdk.internal.vm.annotation.NullRestricted not found
> 1 error
> error: compilation failed
>
> If instead, I first compile and then run, there is no issue.
>
> ---
> public class ComplexBox {
>    public value record Complex(int re, int im) {}
>
>    private Complex! complex;
>
>    public ComplexBox(Complex! complex) {
>      this.complex = complex;
>      super();
>    }
>
>    @Override
>    public String toString() {
>      return "ComplexBox (" + complex + ")";
>    }
>
>    // -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlineLayout
>    static void main() {
>      var complex = new Complex(2, 1);
>      var box = new ComplexBox(complex);
>
>      IO.println(box);
>    }
> }

From jlahoda at openjdk.org  Wed Feb  4 19:38:17 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Feb 2026 19:38:17 GMT
Subject: RFR: Support for transient jdk.internal.vm.annotation.NullRestricted.
Message-ID: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>

Please see:
https://mail.openjdk.org/pipermail/valhalla-dev/2026-February/018513.html

This is an interaction between how `--release` works, the source launcher's use of `--release` and the (I believe) temporary use of non-public `jdk.internal.vm.annotation.NullRestricted`.

- the source launcher will use an automatic `--release` parameter for the internal javac run.
- the `--release` data (mostly) do not contain non-exported, non-public types. There is a handful of exceptions that are needed to keep the semantics correct, like java.lang.AbstractStringBuilder and jdk.internal.event.Event.
- in bworld, javac will insert a synthetic annotation @jdk.internal.vm.annotation.NullRestricted, and since the annotation is not on the system path, as it is not in the `--release` data, the compilation will fail.

My understanding is that the use of @jdk.internal.vm.annotation.NullRestricted is temporary/transient. This PR adds a (transient) support for keeping the annotation in ct.sym, only for the current/development JDK version.

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

Commit messages:
 - Support for transient jdk.internal.vm.annotation.NullRestricted.

Changes: https://git.openjdk.org/valhalla/pull/2039/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2039&range=00
  Stats: 66 lines in 2 files changed: 60 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/2039.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2039/head:pull/2039

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

From mcimadamore at openjdk.org  Wed Feb  4 19:38:18 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Feb 2026 19:38:18 GMT
Subject: RFR: Support for transient
 jdk.internal.vm.annotation.NullRestricted.
In-Reply-To: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
References: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
Message-ID: <5mVSK97J9XJklNRREp0DCV2t3D39r-po-bafKoFvOlk=.f3ba5897-27ed-4c18-825e-28c18be8fbb6@github.com>

On Wed, 4 Feb 2026 19:31:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Please see:
> https://mail.openjdk.org/pipermail/valhalla-dev/2026-February/018513.html
> 
> This is an interaction between how `--release` works, the source launcher's use of `--release` and the (I believe) temporary use of non-public `jdk.internal.vm.annotation.NullRestricted`.
> 
> - the source launcher will use an automatic `--release` parameter for the internal javac run.
> - the `--release` data (mostly) do not contain non-exported, non-public types. There is a handful of exceptions that are needed to keep the semantics correct, like java.lang.AbstractStringBuilder and jdk.internal.event.Event.
> - in bworld, javac will insert a synthetic annotation @jdk.internal.vm.annotation.NullRestricted, and since the annotation is not on the system path, as it is not in the `--release` data, the compilation will fail.
> 
> My understanding is that the use of @jdk.internal.vm.annotation.NullRestricted is temporary/transient. This PR adds a (transient) support for keeping the annotation in ct.sym, only for the current/development JDK version.

Marked as reviewed by mcimadamore (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/2039#pullrequestreview-3752980776

From vromero at openjdk.org  Wed Feb  4 19:49:59 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 19:49:59 GMT
Subject: RFR: Support for transient
 jdk.internal.vm.annotation.NullRestricted.
In-Reply-To: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
References: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
Message-ID: <xuXsjkIVu44i0Typejk8rXjs2PScno3j90FOESW1RqA=.e2dc9fe0-b21b-42c6-a0cd-027916f53c75@github.com>

On Wed, 4 Feb 2026 19:31:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Please see:
> https://mail.openjdk.org/pipermail/valhalla-dev/2026-February/018513.html
> 
> This is an interaction between how `--release` works, the source launcher's use of `--release` and the (I believe) temporary use of non-public `jdk.internal.vm.annotation.NullRestricted`.
> 
> - the source launcher will use an automatic `--release` parameter for the internal javac run.
> - the `--release` data (mostly) do not contain non-exported, non-public types. There is a handful of exceptions that are needed to keep the semantics correct, like java.lang.AbstractStringBuilder and jdk.internal.event.Event.
> - in bworld, javac will insert a synthetic annotation @jdk.internal.vm.annotation.NullRestricted, and since the annotation is not on the system path, as it is not in the `--release` data, the compilation will fail.
> 
> My understanding is that the use of @jdk.internal.vm.annotation.NullRestricted is temporary/transient. This PR adds a (transient) support for keeping the annotation in ct.sym, only for the current/development JDK version.

lgtm

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2039#pullrequestreview-3753027945

From fparain at openjdk.org  Wed Feb  4 20:39:13 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 4 Feb 2026 20:39:13 GMT
Subject: [lworld] RFR: 8376814: [lworld] ValueCompositionTest doesn't support
 NULLABLE_NON_ATOMIC_FLAT layout
Message-ID: <Fl28ejBn_dm-nkogN2D4lFcB7dGAeG19jhxO665Eplc=.30d47c8e-c823-4095-bd21-46ff12fe1964@github.com>

Simple test update to cover NULLABLE_NON_ATOMIC_FLAT layout.

Tested with Mach5 tier1.

Fred

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

Commit messages:
 - Update test to cover NULLABLE_NON_ATOMIC_FLAT

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

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

From liach at openjdk.org  Wed Feb  4 20:51:21 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 20:51:21 GMT
Subject: RFR: Support for transient
 jdk.internal.vm.annotation.NullRestricted.
In-Reply-To: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
References: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
Message-ID: <_Bs81bdc0iSU24b18m1uoNYCHypjcVqyY3MEmePkizM=.baed2158-5e97-4af0-9fa8-04e457e9febd@github.com>

On Wed, 4 Feb 2026 19:31:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Please see:
> https://mail.openjdk.org/pipermail/valhalla-dev/2026-February/018513.html
> 
> This is an interaction between how `--release` works, the source launcher's use of `--release` and the (I believe) temporary use of non-public `jdk.internal.vm.annotation.NullRestricted`.
> 
> - the source launcher will use an automatic `--release` parameter for the internal javac run.
> - the `--release` data (mostly) do not contain non-exported, non-public types. There is a handful of exceptions that are needed to keep the semantics correct, like java.lang.AbstractStringBuilder and jdk.internal.event.Event.
> - in bworld, javac will insert a synthetic annotation @jdk.internal.vm.annotation.NullRestricted, and since the annotation is not on the system path, as it is not in the `--release` data, the compilation will fail.
> 
> My understanding is that the use of @jdk.internal.vm.annotation.NullRestricted is temporary/transient. This PR adds a (transient) support for keeping the annotation in ct.sym, only for the current/development JDK version.

Before we proceed, let me see if we can patch classFileParser to detect ACC_NULL_CHECKED and make it behave like NullRestricted.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2039#issuecomment-3849675257

From vromero at openjdk.org  Wed Feb  4 21:18:08 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 21:18:08 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest [v2]
In-Reply-To: <pdYB9t2zlDFHNONan1ugVNPDxb56nFMt9qN3CNcHbOw=.d7c31bbb-f701-438c-91db-766888db54fa@github.com>
References: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>
 <pdYB9t2zlDFHNONan1ugVNPDxb56nFMt9qN3CNcHbOw=.d7c31bbb-f701-438c-91db-766888db54fa@github.com>
Message-ID: <KI2T1CrnSr_Hxc4nXoSTSlu6wqn_x1dDYlVQvOl3eKE=.10348fb5-2ada-4ae7-ad89-313104ed3a20@github.com>

On Wed, 4 Feb 2026 19:01:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When we read a class file and decode the access flag, we should use the class file's version to decode the flag, so we won't get spurious SUPER and IDENTITY mismatches.
>
> 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 three additional commits since the last revision:
> 
>  - Fix version parse bug, improve coverage
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/accessflags-pass-cffv
>  - 8366270

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 161:

> 159:     }
> 160: 
> 161:     public int classFileVersion() {

shouldn't this method be declared in ClassReader and overridden here?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2036#discussion_r2766001274

From liach at openjdk.org  Wed Feb  4 21:18:09 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 21:18:09 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest [v2]
In-Reply-To: <KI2T1CrnSr_Hxc4nXoSTSlu6wqn_x1dDYlVQvOl3eKE=.10348fb5-2ada-4ae7-ad89-313104ed3a20@github.com>
References: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>
 <pdYB9t2zlDFHNONan1ugVNPDxb56nFMt9qN3CNcHbOw=.d7c31bbb-f701-438c-91db-766888db54fa@github.com>
 <KI2T1CrnSr_Hxc4nXoSTSlu6wqn_x1dDYlVQvOl3eKE=.10348fb5-2ada-4ae7-ad89-313104ed3a20@github.com>
Message-ID: <h8YmxzFb99B08EBoMHidXTWv4Efh997sbN-0YYXbp5Q=.623cfcb8-b2c1-4e46-a772-572f42673578@github.com>

On Wed, 4 Feb 2026 21:13:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Fix version parse bug, improve coverage
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/accessflags-pass-cffv
>>  - 8366270
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 161:
> 
>> 159:     }
>> 160: 
>> 161:     public int classFileVersion() {
> 
> shouldn't this method be declared in ClassReader and overridden here?

`ClassReader` is a public API in java.lang.classfile, I don't want to touch java.* APIs for now

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2036#discussion_r2766007406

From rriggs at openjdk.org  Wed Feb  4 21:27:42 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 4 Feb 2026 21:27:42 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v2]
In-Reply-To: <5qLNjU_1skgG_vvIVZFECvaN5uWXsC8nA_2TIX_WfOE=.b6b7e6b3-831d-40f3-a0a1-7bba4e30cbe4@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <5qLNjU_1skgG_vvIVZFECvaN5uWXsC8nA_2TIX_WfOE=.b6b7e6b3-831d-40f3-a0a1-7bba4e30cbe4@github.com>
Message-ID: <8qPYo-PuuQcYRy20_nSJHFYPM6U5Xd-wwz3-EP2xUFc=.1995a9f6-6505-48d4-8055-b45753df5b2a@github.com>

On Wed, 4 Feb 2026 17:36:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove strict_init from Modifier

src/java.base/share/classes/java/lang/invoke/MemberName.java line 396:

> 394:     public boolean isStrict() {
> 395:         return Modifier.isStrict(flags);
> 396:     }

It seems that this `Membername.isStrict()` is unused, can it/should it be removed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2025#discussion_r2766040475

From vromero at openjdk.org  Wed Feb  4 21:48:47 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 21:48:47 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest [v2]
In-Reply-To: <pdYB9t2zlDFHNONan1ugVNPDxb56nFMt9qN3CNcHbOw=.d7c31bbb-f701-438c-91db-766888db54fa@github.com>
References: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>
 <pdYB9t2zlDFHNONan1ugVNPDxb56nFMt9qN3CNcHbOw=.d7c31bbb-f701-438c-91db-766888db54fa@github.com>
Message-ID: <OuMekK8MgsA0vtQv-vnFFPn8833qi6ZTj5Bf3Dp1QIE=.37b655c3-6458-4911-ba91-d3cf47093155@github.com>

On Wed, 4 Feb 2026 19:01:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When we read a class file and decode the access flag, we should use the class file's version to decode the flag, so we won't get spurious SUPER and IDENTITY mismatches.
>
> 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 three additional commits since the last revision:
> 
>  - Fix version parse bug, improve coverage
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/accessflags-pass-cffv
>  - 8366270

lgtm

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2036#pullrequestreview-3753460643

From liach at openjdk.org  Wed Feb  4 21:50:43 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 21:50:43 GMT
Subject: RFR: Support for transient
 jdk.internal.vm.annotation.NullRestricted.
In-Reply-To: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
References: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
Message-ID: <2Wsy9kyjJDVHBJUSykDMfDUFbH53HlLNkxiolDhsqfo=.caffb442-9578-44de-bc11-e28abcbdba9d@github.com>

On Wed, 4 Feb 2026 19:31:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Please see:
> https://mail.openjdk.org/pipermail/valhalla-dev/2026-February/018513.html
> 
> This is an interaction between how `--release` works, the source launcher's use of `--release` and the (I believe) temporary use of non-public `jdk.internal.vm.annotation.NullRestricted`.
> 
> - the source launcher will use an automatic `--release` parameter for the internal javac run.
> - the `--release` data (mostly) do not contain non-exported, non-public types. There is a handful of exceptions that are needed to keep the semantics correct, like java.lang.AbstractStringBuilder and jdk.internal.event.Event.
> - in bworld, javac will insert a synthetic annotation @jdk.internal.vm.annotation.NullRestricted, and since the annotation is not on the system path, as it is not in the `--release` data, the compilation will fail.
> 
> My understanding is that the use of @jdk.internal.vm.annotation.NullRestricted is temporary/transient. This PR adds a (transient) support for keeping the annotation in ct.sym, only for the current/development JDK version.

I have created a VM-side fix in #2041, we don't need to hack CreateSymbols and javac any more.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2039#issuecomment-3849920503

From liach at openjdk.org  Wed Feb  4 21:50:57 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 21:50:57 GMT
Subject: RFR: JVM detect null checked flag
Message-ID: <i7qBWEQszMClaWSqTVPyi4E1elIuWtMwGVT4hHgZivQ=.151db290-b342-411d-90a0-2ca8fc402e34@github.com>

`test/jdk/valhalla/valuetypes/Reflection.java` confirms that a value `!` field now generates the same VM field flag as `@NullRestricted`; this is verified by `ValueClass.isNullRestrictedField` which reads from the VM field flag.

We can now throw away the javac hack that injects `@NullRestricted`.

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

Commit messages:
 - JVM detect null checked flag

Changes: https://git.openjdk.org/valhalla/pull/2041/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2041&range=00
  Stats: 94 lines in 16 files changed: 20 ins; 48 del; 26 mod
  Patch: https://git.openjdk.org/valhalla/pull/2041.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2041/head:pull/2041

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

From vromero at openjdk.org  Wed Feb  4 22:05:32 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Feb 2026 22:05:32 GMT
Subject: RFR: JVM detect null checked flag
In-Reply-To: <i7qBWEQszMClaWSqTVPyi4E1elIuWtMwGVT4hHgZivQ=.151db290-b342-411d-90a0-2ca8fc402e34@github.com>
References: <i7qBWEQszMClaWSqTVPyi4E1elIuWtMwGVT4hHgZivQ=.151db290-b342-411d-90a0-2ca8fc402e34@github.com>
Message-ID: <5xZ3hHPhEKHzay9GADPR7Znn_2LUW6XGQDOpT0Rw5Ks=.114dc765-1d3a-4798-9edf-cc836a572a78@github.com>

On Wed, 4 Feb 2026 21:44:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> `test/jdk/valhalla/valuetypes/Reflection.java` confirms that a value `!` field now generates the same VM field flag as `@NullRestricted`; this is verified by `ValueClass.isNullRestrictedField` which reads from the VM field flag.
> 
> We can now throw away the javac hack that injects `@NullRestricted`.

lgtm

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2041#pullrequestreview-3753513516

From liach at openjdk.org  Wed Feb  4 22:17:32 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 22:17:32 GMT
Subject: RFR: JVM detect null checked flag
In-Reply-To: <i7qBWEQszMClaWSqTVPyi4E1elIuWtMwGVT4hHgZivQ=.151db290-b342-411d-90a0-2ca8fc402e34@github.com>
References: <i7qBWEQszMClaWSqTVPyi4E1elIuWtMwGVT4hHgZivQ=.151db290-b342-411d-90a0-2ca8fc402e34@github.com>
Message-ID: <7cNPqZiaUMjylS8w8VpKPvNacloUW21sFQ_hqEHYuII=.95cb956f-0e42-48e2-b340-1fc1e2142eef@github.com>

On Wed, 4 Feb 2026 21:44:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> `test/jdk/valhalla/valuetypes/Reflection.java` confirms that a value `!` field now generates the same VM field flag as `@NullRestricted`; this is verified by `ValueClass.isNullRestrictedField` which reads from the VM field flag.
> 
> We can now throw away the javac hack that injects `@NullRestricted`.

Thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/2041#issuecomment-3850008245

From liach at openjdk.org  Wed Feb  4 22:17:33 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 22:17:33 GMT
Subject: Integrated: JVM detect null checked flag
In-Reply-To: <i7qBWEQszMClaWSqTVPyi4E1elIuWtMwGVT4hHgZivQ=.151db290-b342-411d-90a0-2ca8fc402e34@github.com>
References: <i7qBWEQszMClaWSqTVPyi4E1elIuWtMwGVT4hHgZivQ=.151db290-b342-411d-90a0-2ca8fc402e34@github.com>
Message-ID: <Gf2AWcS9wl_YYYgBqlZLcgUZXVqnl-hfhU5cBje35kE=.8ffb5c62-f722-4a1c-ac29-78d34cb1b587@github.com>

On Wed, 4 Feb 2026 21:44:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> `test/jdk/valhalla/valuetypes/Reflection.java` confirms that a value `!` field now generates the same VM field flag as `@NullRestricted`; this is verified by `ValueClass.isNullRestrictedField` which reads from the VM field flag.
> 
> We can now throw away the javac hack that injects `@NullRestricted`.

This pull request has now been integrated.

Changeset: cd5163f5
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cd5163f5093c4e6ea0fdf7f0400590518cfe2272
Stats:     94 lines in 16 files changed: 20 ins; 48 del; 26 mod

JVM detect null checked flag

Reviewed-by: vromero

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

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

From matsaave at openjdk.org  Wed Feb  4 22:20:30 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 4 Feb 2026 22:20:30 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v3]
In-Reply-To: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
Message-ID: <k1ZCCsRI5ZPfCZg-GP1R59GIve2bCkm8iMInrui4XfA=.c4cff024-61b7-473d-925d-be1048641954@github.com>

> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Chen and Roger commentS

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2025/files
  - new: https://git.openjdk.org/valhalla/pull/2025/files/b2c024b1..e16f0b0a

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

  Stats: 13 lines in 9 files changed: 0 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/2025.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2025/head:pull/2025

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

From rriggs at openjdk.org  Wed Feb  4 22:51:42 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 4 Feb 2026 22:51:42 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v3]
In-Reply-To: <k1ZCCsRI5ZPfCZg-GP1R59GIve2bCkm8iMInrui4XfA=.c4cff024-61b7-473d-925d-be1048641954@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <k1ZCCsRI5ZPfCZg-GP1R59GIve2bCkm8iMInrui4XfA=.c4cff024-61b7-473d-925d-be1048641954@github.com>
Message-ID: <gBuwmdUTDS09qh-2KUbENypyR5INij1ZRu6pmhABTCE=.c383cbd5-a5ec-40b9-a1d9-5501235e07ab@github.com>

On Wed, 4 Feb 2026 22:20:30 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen and Roger commentS

src/java.base/share/classes/java/lang/invoke/MemberName.java line 393:

> 391:         return Modifier.isFinal(flags);
> 392:     }
> 393:      /** Utility method to query the modifier flags of this member. */

Odd leading space here.  Also the comment should mention the strict flag it is testing.
Otherwise, the comments for all the utility methods are the same, generic, uninformative.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2025#discussion_r2766303945

From liach at openjdk.org  Wed Feb  4 22:57:26 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 22:57:26 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v3]
In-Reply-To: <gBuwmdUTDS09qh-2KUbENypyR5INij1ZRu6pmhABTCE=.c383cbd5-a5ec-40b9-a1d9-5501235e07ab@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <k1ZCCsRI5ZPfCZg-GP1R59GIve2bCkm8iMInrui4XfA=.c4cff024-61b7-473d-925d-be1048641954@github.com>
 <gBuwmdUTDS09qh-2KUbENypyR5INij1ZRu6pmhABTCE=.c383cbd5-a5ec-40b9-a1d9-5501235e07ab@github.com>
Message-ID: <YGkG0h6n6P9GgY_Kl6eKIl-tIv7dg25_NeVZz_I28bY=.6fbea1a2-8caf-46dc-925c-a97dd6cc4d93@github.com>

On Wed, 4 Feb 2026 22:49:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chen and Roger commentS
>
> src/java.base/share/classes/java/lang/invoke/MemberName.java line 393:
> 
>> 391:         return Modifier.isFinal(flags);
>> 392:     }
>> 393:      /** Utility method to query the modifier flags of this member. */
> 
> Odd leading space here.  Also the comment should mention the strict flag it is testing.
> Otherwise, the comments for all the utility methods are the same, generic, uninformative.

All flag query methods have this simple comment in MemberName. I think we can fix those later.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2025#discussion_r2766317769

From rriggs at openjdk.org  Wed Feb  4 23:10:09 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 4 Feb 2026 23:10:09 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v3]
In-Reply-To: <YGkG0h6n6P9GgY_Kl6eKIl-tIv7dg25_NeVZz_I28bY=.6fbea1a2-8caf-46dc-925c-a97dd6cc4d93@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <k1ZCCsRI5ZPfCZg-GP1R59GIve2bCkm8iMInrui4XfA=.c4cff024-61b7-473d-925d-be1048641954@github.com>
 <gBuwmdUTDS09qh-2KUbENypyR5INij1ZRu6pmhABTCE=.c383cbd5-a5ec-40b9-a1d9-5501235e07ab@github.com>
 <YGkG0h6n6P9GgY_Kl6eKIl-tIv7dg25_NeVZz_I28bY=.6fbea1a2-8caf-46dc-925c-a97dd6cc4d93@github.com>
Message-ID: <cqzhtzgrMbGfd3FIpBluf2GGL3C8CaKIneutWl82UI8=.5e33444d-ae75-4f8c-b159-3abb3579feda@github.com>

On Wed, 4 Feb 2026 22:54:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MemberName.java line 393:
>> 
>>> 391:         return Modifier.isFinal(flags);
>>> 392:     }
>>> 393:      /** Utility method to query the modifier flags of this member. */
>> 
>> Odd leading space here.  Also the comment should mention the strict flag it is testing.
>> Otherwise, the comments for all the utility methods are the same, generic, uninformative.
>
> All flag query methods have this simple comment in MemberName. I think we can fix those later.

It is in the scope of this PR to fix this one.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2025#discussion_r2766347871

From liach at openjdk.org  Wed Feb  4 23:10:11 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 23:10:11 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v3]
In-Reply-To: <k1ZCCsRI5ZPfCZg-GP1R59GIve2bCkm8iMInrui4XfA=.c4cff024-61b7-473d-925d-be1048641954@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <k1ZCCsRI5ZPfCZg-GP1R59GIve2bCkm8iMInrui4XfA=.c4cff024-61b7-473d-925d-be1048641954@github.com>
Message-ID: <04tyEWJPD4ItLZR96OxokHCB0sCbwdhcmvAgoXvkDoA=.e12735ab-42d5-4cdc-83e2-0c51b5608f90@github.com>

On Wed, 4 Feb 2026 22:20:30 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen and Roger commentS

src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/Constants.java line 2:

> 1: /*
> 2:  * Copyright (c) 2009, 2026. Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2009, 2026, Oracle and/or its affiliates. All rights reserved.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2025#discussion_r2766342860

From liach at openjdk.org  Wed Feb  4 23:15:27 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 23:15:27 GMT
Subject: RFR: [bworld] BasicAccessFlags and JavaBaseCheckSince failing
Message-ID: <wBFH-CAjHGeEGFJCd4GYhFUN6auOYziMUZYmk5KNJBo=.a7a44824-2a68-4cb3-ab1c-945ff798ea4b@github.com>

NULL_CHECKED with mask 0x200 should be ranked near INTERFACE which also has 0x200. Checks need to use `@since Valhalla` instead of `valhalla` to inform `JavaBaseCheckSince`. These are the test failures I see from running tier 1 and 2 on Oracle's CI.

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

Commit messages:
 - [bworld] BasicAccessFlags and JavaBaseCheckSince failing

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

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

From liach at openjdk.org  Wed Feb  4 23:44:07 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 23:44:07 GMT
Subject: Integrated: [bworld] BasicAccessFlags and JavaBaseCheckSince failing
In-Reply-To: <wBFH-CAjHGeEGFJCd4GYhFUN6auOYziMUZYmk5KNJBo=.a7a44824-2a68-4cb3-ab1c-945ff798ea4b@github.com>
References: <wBFH-CAjHGeEGFJCd4GYhFUN6auOYziMUZYmk5KNJBo=.a7a44824-2a68-4cb3-ab1c-945ff798ea4b@github.com>
Message-ID: <MSMoHcDq6TolU1aAy6IFcKj4VkAtp1vMlZ528zHKIJU=.fb3f1b5a-7fd3-4319-82b1-410a904015a3@github.com>

On Wed, 4 Feb 2026 23:09:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> NULL_CHECKED with mask 0x200 should be ranked near INTERFACE which also has 0x200. Checks need to use `@since Valhalla` instead of `valhalla` to inform `JavaBaseCheckSince`. These are the test failures I see from running tier 1 and 2 on Oracle's CI.

This pull request has now been integrated.

Changeset: 5d9e878e
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5d9e878e9cfd4260a93df8be9f66c526be0dce56
Stats:     25 lines in 2 files changed: 12 ins; 12 del; 1 mod

[bworld] BasicAccessFlags and JavaBaseCheckSince failing

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

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

From vromero at openjdk.org  Thu Feb  5 01:41:55 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Feb 2026 01:41:55 GMT
Subject: RFR: [bworld] javac crash for abstract methods with null restricted
 arguments
Message-ID: <oDyqZTeo6IOsa0WU_BhbbfKMi9MozPC4Luylxz2tSFQ=.0b073aec-8b58-4be5-82b8-24158e6defe5@github.com>

fixing a silly bug, basically javac can crash for code like:


abstract class I {
    abstract void m(String! s);
}

javac was trying to access the method's body but it is null

TIA

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

Commit messages:
 - minor fix
 - [bworld] javac crash for abstract methods with null restricted arguments

Changes: https://git.openjdk.org/valhalla/pull/2044/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2044&range=00
  Stats: 30 lines in 2 files changed: 21 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/2044.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2044/head:pull/2044

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

From vromero at openjdk.org  Thu Feb  5 02:51:00 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Feb 2026 02:51:00 GMT
Subject: RFR: [bworld] fixing regression tests
Message-ID: <8b43rDkIuT2O6THk1pfwqnSAolNHQvbm56NL2DnH4cU=.fcc819b5-a43f-4904-81d9-ec9615060948@github.com>

this PR is fixing the rest of the regression tests failing in bworld, after this all tier1-3 tests should pass

TIA

PS, the tests failing are:
open/test/jdk/tools/sincechecker/modules/java.base/JavaBaseCheckSince.java  and
open/test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java

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

Commit messages:
 - [bworld] fixing regression tests

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

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

From liach at openjdk.org  Thu Feb  5 02:59:40 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 02:59:40 GMT
Subject: RFR: [bworld] fixing regression tests
In-Reply-To: <8b43rDkIuT2O6THk1pfwqnSAolNHQvbm56NL2DnH4cU=.fcc819b5-a43f-4904-81d9-ec9615060948@github.com>
References: <8b43rDkIuT2O6THk1pfwqnSAolNHQvbm56NL2DnH4cU=.fcc819b5-a43f-4904-81d9-ec9615060948@github.com>
Message-ID: <eZ_QnfwGfFZDAkIDtb08RtquHBPjrjDPtK9DjIZRTII=.9978edc6-e3aa-4158-abfe-ce098452c222@github.com>

On Thu, 5 Feb 2026 02:45:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this PR is fixing the rest of the regression tests failing in bworld, after this all tier1-3 tests should pass
> 
> TIA
> 
> PS, the tests failing are:
> open/test/jdk/tools/sincechecker/modules/java.base/JavaBaseCheckSince.java  and
> open/test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/2045#pullrequestreview-3754250419

From liach at openjdk.org  Thu Feb  5 03:02:26 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 03:02:26 GMT
Subject: RFR: [bworld] javac crash for abstract methods with null
 restricted arguments
In-Reply-To: <oDyqZTeo6IOsa0WU_BhbbfKMi9MozPC4Luylxz2tSFQ=.0b073aec-8b58-4be5-82b8-24158e6defe5@github.com>
References: <oDyqZTeo6IOsa0WU_BhbbfKMi9MozPC4Luylxz2tSFQ=.0b073aec-8b58-4be5-82b8-24158e6defe5@github.com>
Message-ID: <HLAUS4fv8EwhZawVNZRcmzpQ4NCJJQRyftyRQxTfxck=.6765cb1c-2065-45ad-90e3-5f3a36ea4c9c@github.com>

On Thu, 5 Feb 2026 01:31:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing a silly bug, basically javac can crash for code like:
> 
> 
> abstract class I {
>     abstract void m(String! s);
> }
> 
> javac was trying to access the method's body but it is `null` for abstract methods
> 
> TIA

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/2044#pullrequestreview-3754256409

From qamai at openjdk.org  Thu Feb  5 05:09:10 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 5 Feb 2026 05:09:10 GMT
Subject: [lworld] RFR: 8376213: [lworld] C2: assert(is_InlineType())
 failed: invalid node class: Phi/LoadP/DecodeN [v2]
In-Reply-To: <UwwpAqM5PVMCyjFvkQxrHDEIMwYhZLHwgVseNuM2-I8=.646b6f7d-2abe-4d61-bc01-28609a64dcc7@github.com>
References: <UwwpAqM5PVMCyjFvkQxrHDEIMwYhZLHwgVseNuM2-I8=.646b6f7d-2abe-4d61-bc01-28609a64dcc7@github.com>
Message-ID: <gaXexTs20jSUD3aouBXClrOt73s8_5CrshojcHgfGYE=.9843cb3c-a740-4f53-be58-7908183fb7ac@github.com>

> Hi,
> 
> The issue here is that not all fields of inline types are expanded to `InlineTypeNode`s. The decision to expand them should have been done when we obtain the object, so we just need to check if the field value is a `InlineTypeNode` here.
> 
> Testing:
> 
> - [x] tier1-4,valhalla-comp-stress, Linux-x64
> 
> Please kindly review, thanks a lot.

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

  Need to check the field type, too

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2035/files
  - new: https://git.openjdk.org/valhalla/pull/2035/files/c121ccc1..77a83d84

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

  Stats: 20 lines in 2 files changed: 17 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/2035.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2035/head:pull/2035

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

From darcy at openjdk.org  Thu Feb  5 06:09:03 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 06:09:03 GMT
Subject: RFR: [type-classes] 8377195: Add prototype complex type using polar
 coordinates
Message-ID: <Zlj6Kah0_aOrKTJLgUudla7ihd0o8ehRaIs2DsvcwW4=.54b71ea1-018d-4b31-840d-0d8cfc46ce76@github.com>

Adding a second flavor of complex numbers with bi-directional conversions.

Also included Numerical witnesses on both flavors of complex.

For now, removing the deprecation annotations to make use in jshell less verbose.

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

Commit messages:
 - 8377195: Add prototype complex type using polar coordinates

Changes: https://git.openjdk.org/valhalla/pull/2046/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2046&range=00
  Stats: 529 lines in 2 files changed: 520 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/2046.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2046/head:pull/2046

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

From thartmann at openjdk.org  Thu Feb  5 06:37:01 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 5 Feb 2026 06:37:01 GMT
Subject: [lworld] Integrated: 8376733: [lworld] Inconsistent result of
 Invoke::declared_type triggers assert in profiling
In-Reply-To: <TzLN7lPwoJDBMkyY5sCY2oH7mVnS7Oyx9OGpB3lL-84=.367f6412-6b0a-4252-af1f-43e8e00ee8ce@github.com>
References: <TzLN7lPwoJDBMkyY5sCY2oH7mVnS7Oyx9OGpB3lL-84=.367f6412-6b0a-4252-af1f-43e8e00ee8ce@github.com>
Message-ID: <b477pzz8EgwBH5NKSpxoptlbx3kZcjzegLVrPbCl108=.58536401-154f-4632-b62a-474ff2bd3418@github.com>

On Wed, 4 Feb 2026 12:47:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Old mainline fix [JDK-8134389](https://bugs.openjdk.org/browse/JDK-8134389) modified code in `Invoke::declared_type` to not use the return type of the target signature but use the declared signature instead (see [changeset](https://hg.openjdk.org/jdk9/jdk9/hotspot/rev/4191b33b3629) for details). This was needed for method handle call sites to return `java/lang/invoke/CallSite` instead of `java/lang/Object` or whatever the target method return type would look like. The test `compiler/jsr292/TestArrayReturnType.java` still reliably triggers this scenario.
> 
> Now the problem is that the return type is re-computed on every call to `Invoke::declared_type` but it might actually change from unloaded to loaded in-between and therefore different `ciType` objects will be returned. In the failing case, the return type first is
> `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=false ident=1498 address=0x00007ae57d775728>` 
> and later it's `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=true ident=1508 address=0x00007ae57d7762a8>` (note the different `loaded` property). This leads to an assertion failure in profiling because we invoke CHA to improve a type that's already final because when we checked the type earlier, it was still unloaded.
> 
> I think it's a general rule that the compiler interface needs to guarantee consistency of types during compilation and therefore I adjusted the code to only compute the return type once. This is a mainline issue and could be fixed in mainline as well. However, as far as I can tell, only Valhalla is currently affected because the Valhalla specific array load/store profiling uses `LIRGenerator::profile_type` in more cases. Let's therefore only fix it in Valhalla for now.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 63d9c437
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/63d9c437e4a70b3bf3708ad872c92ecabdf862c9
Stats:     17 lines in 3 files changed: 3 ins; 2 del; 12 mod

8376733: [lworld] Inconsistent result of Invoke::declared_type triggers assert in profiling

Reviewed-by: chagedorn

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

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

From thartmann at openjdk.org  Thu Feb  5 06:41:58 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 5 Feb 2026 06:41:58 GMT
Subject: [lworld] RFR: 8376213: [lworld] C2: assert(is_InlineType())
 failed: invalid node class: Phi/LoadP/DecodeN [v2]
In-Reply-To: <gaXexTs20jSUD3aouBXClrOt73s8_5CrshojcHgfGYE=.9843cb3c-a740-4f53-be58-7908183fb7ac@github.com>
References: <UwwpAqM5PVMCyjFvkQxrHDEIMwYhZLHwgVseNuM2-I8=.646b6f7d-2abe-4d61-bc01-28609a64dcc7@github.com>
 <gaXexTs20jSUD3aouBXClrOt73s8_5CrshojcHgfGYE=.9843cb3c-a740-4f53-be58-7908183fb7ac@github.com>
Message-ID: <iiE6qiV7QD94MWeC14J8Q4TwASoRGY_jvt-eBSR5EPM=.384db2a4-75f8-4b30-9895-1130909d4f0e@github.com>

On Thu, 5 Feb 2026 05:09:10 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> The issue here is that not all fields of inline types are expanded to `InlineTypeNode`s. The decision to expand them should have been done when we obtain the object, so we just need to check if the field value is a `InlineTypeNode` here.
>> 
>> Testing:
>> 
>> - [x] tier1-4,valhalla-comp-stress, Linux-x64
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Need to check the field type, too

Looks good to me!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2035#pullrequestreview-3754833128

From thartmann at openjdk.org  Thu Feb  5 06:45:52 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 5 Feb 2026 06:45:52 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer
In-Reply-To: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
Message-ID: <NSHge_q7xQ0DJsSsqLNJgOD176-bfufYnZSKE9PmHzA=.e6977d6e-70dd-42ca-be49-139334608b66@github.com>

On Mon, 2 Feb 2026 23:34:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...

src/hotspot/share/opto/graphKit.cpp line 3585:

> 3583:   const Type* obj_type = _gvn.type(obj);
> 3584:   if (obj_type->is_inlinetypeptr() && !obj_type->maybe_null() && klass_ptr_type->klass_is_exact() && obj_type->inline_klass() == klass_ptr_type->exact_klass(true)) {
> 3585:     // TODO remnant to support old makePrivateBuffer generic cast, we can probably remove this now

I think this can do. Let me verify and get back to you.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2018#discussion_r2767384913

From qamai at openjdk.org  Thu Feb  5 06:56:36 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 5 Feb 2026 06:56:36 GMT
Subject: [lworld] RFR: 8376213: [lworld] C2: assert(is_InlineType())
 failed: invalid node class: Phi/LoadP/DecodeN [v2]
In-Reply-To: <gaXexTs20jSUD3aouBXClrOt73s8_5CrshojcHgfGYE=.9843cb3c-a740-4f53-be58-7908183fb7ac@github.com>
References: <UwwpAqM5PVMCyjFvkQxrHDEIMwYhZLHwgVseNuM2-I8=.646b6f7d-2abe-4d61-bc01-28609a64dcc7@github.com>
 <gaXexTs20jSUD3aouBXClrOt73s8_5CrshojcHgfGYE=.9843cb3c-a740-4f53-be58-7908183fb7ac@github.com>
Message-ID: <gbOvzaSmthMi3RAH_IUhm1J2q1xuviHK4-OO5WtM4Ww=.b2588d46-59ff-4661-b934-cb5cfe3af88b@github.com>

On Thu, 5 Feb 2026 05:09:10 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> The issue here is that not all fields of inline types are expanded to `InlineTypeNode`s. The decision to expand them should have been done when we obtain the object, so we just need to check if the field value is a `InlineTypeNode` here.
>> 
>> Testing:
>> 
>> - [x] tier1-4,valhalla-comp-stress, Linux-x64
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Need to check the field type, too

Thanks a lot for your approval!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2035#issuecomment-3851398646

From qamai at openjdk.org  Thu Feb  5 06:56:37 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 5 Feb 2026 06:56:37 GMT
Subject: [lworld] Integrated: 8376213: [lworld] C2: assert(is_InlineType())
 failed: invalid node class: Phi/LoadP/DecodeN
In-Reply-To: <UwwpAqM5PVMCyjFvkQxrHDEIMwYhZLHwgVseNuM2-I8=.646b6f7d-2abe-4d61-bc01-28609a64dcc7@github.com>
References: <UwwpAqM5PVMCyjFvkQxrHDEIMwYhZLHwgVseNuM2-I8=.646b6f7d-2abe-4d61-bc01-28609a64dcc7@github.com>
Message-ID: <lUSbFGL2FJrUjaBbzDb0az9Tn4wx2ePVD0i1AO4muxg=.48279d0a-a282-4a6b-b6ca-3e34d9aaa0bd@github.com>

On Wed, 4 Feb 2026 15:55:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue here is that not all fields of inline types are expanded to `InlineTypeNode`s. The decision to expand them should have been done when we obtain the object, so we just need to check if the field value is a `InlineTypeNode` here.
> 
> Testing:
> 
> - [x] tier1-4,valhalla-comp-stress, Linux-x64
> 
> Please kindly review, thanks a lot.

This pull request has now been integrated.

Changeset: e40b636f
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e40b636f388f436103bca2b4e1c4460553fdb81f
Stats:     79 lines in 2 files changed: 77 ins; 0 del; 2 mod

8376213: [lworld] C2: assert(is_InlineType()) failed: invalid node class: Phi/LoadP/DecodeN

Reviewed-by: thartmann

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

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

From jlahoda at openjdk.org  Thu Feb  5 07:25:20 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 5 Feb 2026 07:25:20 GMT
Subject: RFR: Support for transient
 jdk.internal.vm.annotation.NullRestricted.
In-Reply-To: <2Wsy9kyjJDVHBJUSykDMfDUFbH53HlLNkxiolDhsqfo=.caffb442-9578-44de-bc11-e28abcbdba9d@github.com>
References: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
 <2Wsy9kyjJDVHBJUSykDMfDUFbH53HlLNkxiolDhsqfo=.caffb442-9578-44de-bc11-e28abcbdba9d@github.com>
Message-ID: <C5wwyzgoEwRgkzJS2BmfdrQxYQaL0Gfzm_y3H2t0fkI=.abfc186f-5755-4957-9234-fea021887090@github.com>

On Wed, 4 Feb 2026 21:48:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please see:
>> https://mail.openjdk.org/pipermail/valhalla-dev/2026-February/018513.html
>> 
>> This is an interaction between how `--release` works, the source launcher's use of `--release` and the (I believe) temporary use of non-public `jdk.internal.vm.annotation.NullRestricted`.
>> 
>> - the source launcher will use an automatic `--release` parameter for the internal javac run.
>> - the `--release` data (mostly) do not contain non-exported, non-public types. There is a handful of exceptions that are needed to keep the semantics correct, like java.lang.AbstractStringBuilder and jdk.internal.event.Event.
>> - in bworld, javac will insert a synthetic annotation @jdk.internal.vm.annotation.NullRestricted, and since the annotation is not on the system path, as it is not in the `--release` data, the compilation will fail.
>> 
>> My understanding is that the use of @jdk.internal.vm.annotation.NullRestricted is temporary/transient. This PR adds a (transient) support for keeping the annotation in ct.sym, only for the current/development JDK version.
>
> I have created a VM-side fix in #2041, we don't need to hack CreateSymbols and javac any more.

Thanks @liach - seems to work well!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2039#issuecomment-3851507936

From jlahoda at openjdk.org  Thu Feb  5 07:25:22 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 5 Feb 2026 07:25:22 GMT
Subject: Withdrawn: Support for transient
 jdk.internal.vm.annotation.NullRestricted.
In-Reply-To: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
References: <W6vSlLYaH_waumzhtIS0gP9Af-Ar_rNe07c_0NPElSw=.214dfcc1-14f2-4d8f-ac78-a5fe3b2fd182@github.com>
Message-ID: <PKEXgPizfWHuvjE-4Wv-vqXRuh1J2dEJ6B8TK3byCyg=.7e023f08-b933-4dbc-aa66-5bfa02a36a64@github.com>

On Wed, 4 Feb 2026 19:31:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Please see:
> https://mail.openjdk.org/pipermail/valhalla-dev/2026-February/018513.html
> 
> This is an interaction between how `--release` works, the source launcher's use of `--release` and the (I believe) temporary use of non-public `jdk.internal.vm.annotation.NullRestricted`.
> 
> - the source launcher will use an automatic `--release` parameter for the internal javac run.
> - the `--release` data (mostly) do not contain non-exported, non-public types. There is a handful of exceptions that are needed to keep the semantics correct, like java.lang.AbstractStringBuilder and jdk.internal.event.Event.
> - in bworld, javac will insert a synthetic annotation @jdk.internal.vm.annotation.NullRestricted, and since the annotation is not on the system path, as it is not in the `--release` data, the compilation will fail.
> 
> My understanding is that the use of @jdk.internal.vm.annotation.NullRestricted is temporary/transient. This PR adds a (transient) support for keeping the annotation in ct.sym, only for the current/development JDK version.

This pull request has been closed without being integrated.

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

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

From thartmann at openjdk.org  Thu Feb  5 10:24:28 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 5 Feb 2026 10:24:28 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer
In-Reply-To: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
Message-ID: <jyVa-jdKJCsr2BvVlNcNJzy3hBanMdm7XuesHrq2iuM=.05337ddc-1528-4c85-8039-37b387d97aaa@github.com>

On Mon, 2 Feb 2026 23:34:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...

src/hotspot/share/opto/graphKit.cpp line 3587:

> 3585:     // TODO remnant to support old makePrivateBuffer generic cast, we can probably remove this now
> 3586:     return obj;
> 3587:   }

This code can all go away. I run some testing and it looks good.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2018#discussion_r2768185535

From forax at univ-mlv.fr  Thu Feb  5 10:36:47 2026
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 5 Feb 2026 11:36:47 +0100 (CET)
Subject: bworld - java laucher vs restricted field
In-Reply-To: <18742a4c-dae1-4e95-ae18-d3ccf5b1f5d5@oracle.com>
References: <436539784.33563348.1770219780179.JavaMail.zimbra@univ-eiffel.fr>
 <18742a4c-dae1-4e95-ae18-d3ccf5b1f5d5@oracle.com>
Message-ID: <849904051.34199129.1770287807576.JavaMail.zimbra@univ-eiffel.fr>

Hello,
I can confirm that the fix pushed by Chen Liang solves the issue :)

R?mi

----- Original Message -----
> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Cc: "Vicente Romero" <vicente.romero at oracle.com>
> Sent: Wednesday, February 4, 2026 8:32:19 PM
> Subject: Re: bworld - java laucher vs restricted field

> Hi Remi,
> 
> 
> Thanks for the report. Please see for what I think is the cause and a
> possible fix:
> https://github.com/openjdk/valhalla/pull/2039
> 
> 
> Jan
> 
> 
> On 2/4/26 16:43, Remi Forax wrote:
>> Hello,
>> I'm testing the restricted fields on the bworld branch,
>> running the source code directly with the command "java" without using javac
>> failed.
>>
>> step to reproduce:
>>
>> $JAVA_HOME/bin/java --enable-preview ComplexBox.java
>>
>> ComplexBox.java:10: error: cannot access NullRestricted
>> public class ComplexBox {
>>         ^
>>    class file for jdk.internal.vm.annotation.NullRestricted not found
>> 1 error
>> error: compilation failed
>>
>> If instead, I first compile and then run, there is no issue.
>>
>> ---
>> public class ComplexBox {
>>    public value record Complex(int re, int im) {}
>>
>>    private Complex! complex;
>>
>>    public ComplexBox(Complex! complex) {
>>      this.complex = complex;
>>      super();
>>    }
>>
>>    @Override
>>    public String toString() {
>>      return "ComplexBox (" + complex + ")";
>>    }
>>
>>    // -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlineLayout
>>    static void main() {
>>      var complex = new Complex(2, 1);
>>      var box = new ComplexBox(complex);
>>
>>      IO.println(box);
>>    }
> > }

From liach at openjdk.org  Thu Feb  5 12:10:15 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 12:10:15 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer
In-Reply-To: <jyVa-jdKJCsr2BvVlNcNJzy3hBanMdm7XuesHrq2iuM=.05337ddc-1528-4c85-8039-37b387d97aaa@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <jyVa-jdKJCsr2BvVlNcNJzy3hBanMdm7XuesHrq2iuM=.05337ddc-1528-4c85-8039-37b387d97aaa@github.com>
Message-ID: <f3bQ6giJAiO7VnYDvuPdhbCnfbGkHuILzqNdJj8XT_g=.601802b0-987d-4e96-b6bb-0ace5452db35@github.com>

On Thu, 5 Feb 2026 10:21:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> src/hotspot/share/opto/graphKit.cpp line 3587:
> 
>> 3585:     // TODO remnant to support old makePrivateBuffer generic cast, we can probably remove this now
>> 3586:     return obj;
>> 3587:   }
> 
> This code can all go away. I run some testing and it looks good.

This whole if block?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2018#discussion_r2768817012

From liach at openjdk.org  Thu Feb  5 12:10:16 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 12:10:16 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer
In-Reply-To: <f3bQ6giJAiO7VnYDvuPdhbCnfbGkHuILzqNdJj8XT_g=.601802b0-987d-4e96-b6bb-0ace5452db35@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <jyVa-jdKJCsr2BvVlNcNJzy3hBanMdm7XuesHrq2iuM=.05337ddc-1528-4c85-8039-37b387d97aaa@github.com>
 <f3bQ6giJAiO7VnYDvuPdhbCnfbGkHuILzqNdJj8XT_g=.601802b0-987d-4e96-b6bb-0ace5452db35@github.com>
Message-ID: <HcBzyOcJkRCT-LapztuqFERk-ieMI9s1QQpbuoywEik=.01e2c18c-f57f-47a2-8645-e5d80d7b1a5a@github.com>

On Thu, 5 Feb 2026 12:07:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/hotspot/share/opto/graphKit.cpp line 3587:
>> 
>>> 3585:     // TODO remnant to support old makePrivateBuffer generic cast, we can probably remove this now
>>> 3586:     return obj;
>>> 3587:   }
>> 
>> This code can all go away. I run some testing and it looks good.
>
> This whole if block?

This whole if block?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2018#discussion_r2768817129

From qamai at openjdk.org  Thu Feb  5 13:05:35 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 5 Feb 2026 13:05:35 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer
In-Reply-To: <Q5eRwHVbFtGwsggMEmTNN8F2iT77rOKszcSEDc7Y12Y=.89d8fe08-b53b-4c7c-856f-a693c1ac87ca@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <jyVa-jdKJCsr2BvVlNcNJzy3hBanMdm7XuesHrq2iuM=.05337ddc-1528-4c85-8039-37b387d97aaa@github.com>
 <f3bQ6giJAiO7VnYDvuPdhbCnfbGkHuILzqNdJj8XT_g=.601802b0-987d-4e96-b6bb-0ace5452db35@github.com>
 <HcBzyOcJkRCT-LapztuqFERk-ieMI9s1QQpbuoywEik=.01e2c18c-f57f-47a2-8645-e5d80d7b1a5a@github.com>
 <Q5eRwHVbFtGwsggMEmTNN8F2iT77rOKszcSEDc7Y12Y=.89d8fe08-b53b-4c7c-856f-a693c1ac87ca@github.com>
Message-ID: <KR4rfzNkeri4hbStzL_VefuwnO4i6m9vEqFre6Irfy8=.9be640d8-a519-4c0c-bbe6-3b1b236d024c@github.com>

On Thu, 5 Feb 2026 12:57:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This whole if block?
>
> Yes. Maybe @merykitty could double-check though.

Yes the whole if block can be removed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2018#discussion_r2769051526

From cnorrbin at openjdk.org  Thu Feb  5 13:15:04 2026
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 5 Feb 2026 13:15:04 GMT
Subject: [lworld] RFR: 8377242: [lworld] Remove _has_inlined_fields member from
 ClassFileParser
Message-ID: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>

Hi everyone,

This PR removes the redundant `ClassFileParser::_has_inlined_fields` member from ClassFileParser. The value stored in `_has_inlined_fields` is derived directly from `FieldLayoutInfo` and is only used for a getter. Since `ClassFileParser` already retains this in `_layout_info`, a separate duplicate member is unnecessary. With this change, the getter returns the value directly from the stored `FieldLayoutInfo`, removing the extra member while preserving existing behavior.

Testing:
- Tier 1

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

Commit messages:
 - remove _has_inlined_fields in ClassFileParser

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

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

From phubner at openjdk.org  Thu Feb  5 13:15:05 2026
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 5 Feb 2026 13:15:05 GMT
Subject: [lworld] RFR: 8377242: [lworld] Remove _has_inlined_fields member
 from ClassFileParser
In-Reply-To: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
References: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
Message-ID: <f2rimkcaeVOH0qxHUkmasRhRgEtihMlUTegkwh1VgF0=.d1a2f67c-2097-4524-a5e8-5fc4ab11b95e@github.com>

On Thu, 5 Feb 2026 13:07:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This PR removes the redundant `ClassFileParser::_has_inlined_fields` member from ClassFileParser. The value stored in `_has_inlined_fields` is derived directly from `FieldLayoutInfo` and is only used for a getter. Since `ClassFileParser` already retains this in `_layout_info`, a separate duplicate member is unnecessary. With this change, the getter returns the value directly from the stored `FieldLayoutInfo`, removing the extra member while preserving existing behavior.
> 
> Testing:
> - Tier 1

Lgtm, thanks.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2047#pullrequestreview-3756985095

From vromero at openjdk.org  Thu Feb  5 13:17:46 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Feb 2026 13:17:46 GMT
Subject: RFR: [bworld] fixing regression tests
In-Reply-To: <8b43rDkIuT2O6THk1pfwqnSAolNHQvbm56NL2DnH4cU=.fcc819b5-a43f-4904-81d9-ec9615060948@github.com>
References: <8b43rDkIuT2O6THk1pfwqnSAolNHQvbm56NL2DnH4cU=.fcc819b5-a43f-4904-81d9-ec9615060948@github.com>
Message-ID: <TvWyQ5LaXc65sp7yV-eiP_cZbJWbcPIFRHNYJSfidwI=.4f8d450a-7382-4eb2-ab87-cf4b54f264ce@github.com>

On Thu, 5 Feb 2026 02:45:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this PR is fixing the rest of the regression tests failing in bworld, after this all tier1-3 tests should pass
> 
> TIA
> 
> PS, the tests failing are:
> open/test/jdk/tools/sincechecker/modules/java.base/JavaBaseCheckSince.java  and
> open/test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java

@liach thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/2045#issuecomment-3853584862

From vromero at openjdk.org  Thu Feb  5 13:21:07 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Feb 2026 13:21:07 GMT
Subject: RFR: [bworld] javac crash for abstract methods with null
 restricted arguments
In-Reply-To: <oDyqZTeo6IOsa0WU_BhbbfKMi9MozPC4Luylxz2tSFQ=.0b073aec-8b58-4be5-82b8-24158e6defe5@github.com>
References: <oDyqZTeo6IOsa0WU_BhbbfKMi9MozPC4Luylxz2tSFQ=.0b073aec-8b58-4be5-82b8-24158e6defe5@github.com>
Message-ID: <Mjl-A950OIE4_xbE4yBuFsv3nh-8UJWfZpVIUryJAmM=.6ee4ff07-723d-4d2f-9b0e-d7f4cfcf5022@github.com>

On Thu, 5 Feb 2026 01:31:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing a silly bug, basically javac can crash for code like:
> 
> 
> abstract class I {
>     abstract void m(String! s);
> }
> 
> javac was trying to access the method's body but it is `null` for abstract methods
> 
> TIA

@liach thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/2044#issuecomment-3853590610

From vromero at openjdk.org  Thu Feb  5 13:21:08 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Feb 2026 13:21:08 GMT
Subject: Integrated: [bworld] javac crash for abstract methods with null
 restricted arguments
In-Reply-To: <oDyqZTeo6IOsa0WU_BhbbfKMi9MozPC4Luylxz2tSFQ=.0b073aec-8b58-4be5-82b8-24158e6defe5@github.com>
References: <oDyqZTeo6IOsa0WU_BhbbfKMi9MozPC4Luylxz2tSFQ=.0b073aec-8b58-4be5-82b8-24158e6defe5@github.com>
Message-ID: <gvj7oqQYhOc8KQmVNaaPl3gASsiZFrfMRHvAFjL4Q8s=.c11ac8a9-c28b-40f2-9202-76591c7ad5b4@github.com>

On Thu, 5 Feb 2026 01:31:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing a silly bug, basically javac can crash for code like:
> 
> 
> abstract class I {
>     abstract void m(String! s);
> }
> 
> javac was trying to access the method's body but it is `null` for abstract methods
> 
> TIA

This pull request has now been integrated.

Changeset: 1992c3e7
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1992c3e7521740de45a3ffc3eb6975a80c9b53f4
Stats:     30 lines in 2 files changed: 21 ins; 3 del; 6 mod

[bworld] javac crash for abstract methods with null restricted arguments

Reviewed-by: liach

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

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

From vromero at openjdk.org  Thu Feb  5 13:22:11 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Feb 2026 13:22:11 GMT
Subject: Integrated: [bworld] fixing regression tests
In-Reply-To: <8b43rDkIuT2O6THk1pfwqnSAolNHQvbm56NL2DnH4cU=.fcc819b5-a43f-4904-81d9-ec9615060948@github.com>
References: <8b43rDkIuT2O6THk1pfwqnSAolNHQvbm56NL2DnH4cU=.fcc819b5-a43f-4904-81d9-ec9615060948@github.com>
Message-ID: <h3yTar0RFk1bP9dyw5GLVIh4RNCnOk_QvGJc8JkmOok=.61a703bc-6c88-4c7e-999c-7bcd7c5105b8@github.com>

On Thu, 5 Feb 2026 02:45:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this PR is fixing the rest of the regression tests failing in bworld, after this all tier1-3 tests should pass
> 
> TIA
> 
> PS, the tests failing are:
> open/test/jdk/tools/sincechecker/modules/java.base/JavaBaseCheckSince.java  and
> open/test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java

This pull request has now been integrated.

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

[bworld] fixing regression tests

Reviewed-by: liach

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

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

From liach at openjdk.org  Thu Feb  5 13:54:05 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 13:54:05 GMT
Subject: [lworld] RFR: 8377242: [lworld] Remove _has_inlined_fields member
 from ClassFileParser
In-Reply-To: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
References: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
Message-ID: <BB6a7mMsFJWPJiqTAee-ra-8WaYakg2eEabHfcNve0M=.72d67def-a907-466a-917a-dcb00b8d0224@github.com>

On Thu, 5 Feb 2026 13:07:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This PR removes the redundant `ClassFileParser::_has_inlined_fields` member from ClassFileParser. The value stored in `_has_inlined_fields` is derived directly from `FieldLayoutInfo` and is only used for a getter. Since `ClassFileParser` already retains this in `_layout_info`, a separate duplicate member is unnecessary. With this change, the getter returns the value directly from the stored `FieldLayoutInfo`, removing the extra member while preserving existing behavior.
> 
> Testing:
> - Tier 1

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/2047#pullrequestreview-3757258912

From aboldtch at openjdk.org  Thu Feb  5 14:40:40 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 5 Feb 2026 14:40:40 GMT
Subject: [lworld] RFR: 8377243: [lworld]
 HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound
Message-ID: <aKWrKal5eVRcM0iVf-Excgi6u3YHUr2KUXG7YWod8xk=.a734ad6b-7287-4384-97c5-ca889882fd20@github.com>

`IS_DEST_UNINITIALIZED ` is ment to signal to the GC that you cannot read the contents of the field as it is uninitialized. This is used by the compiler which have strict control over its safepoints.

The MemAllocator in the runtime has no such guarantees, and will clear all oop fields before handing the allocated object. These objects can have been seen by the GC and even tenured before the call  `HeapAccess<IS_DEST_UNINITIALIZED>::value_copy`. This is unsound. ZGC for example could miss young to old edges if the destination object had been tenured.

I propose we remove these and always use `HeapAccess<>::value_copy`. The behaviour will be the same for value objects which do not contain oops, and correct of values which contains oops. There is the potential in the future to add something along the lines of `IS_DEST_NULL` to provide more static information to the GC to optimise the barriers on. However the gain here is probably negligible.

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

Commit messages:
 - 8377243: [lworld] HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound

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

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

From fparain at openjdk.org  Thu Feb  5 14:39:19 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 5 Feb 2026 14:39:19 GMT
Subject: [lworld] RFR: 8376814: [lworld] ValueCompositionTest doesn't
 support NULLABLE_NON_ATOMIC_FLAT layout [v2]
In-Reply-To: <Fl28ejBn_dm-nkogN2D4lFcB7dGAeG19jhxO665Eplc=.30d47c8e-c823-4095-bd21-46ff12fe1964@github.com>
References: <Fl28ejBn_dm-nkogN2D4lFcB7dGAeG19jhxO665Eplc=.30d47c8e-c823-4095-bd21-46ff12fe1964@github.com>
Message-ID: <WJ2bNi_LeKcTsyCA4TBJeJDuhAdF7hpROUDJcsf-9A0=.3107190d-52fd-4150-adcc-331f3bd12977@github.com>

> Simple test update to cover NULLABLE_NON_ATOMIC_FLAT layout.
> 
> Tested with Mach5 tier1.
> 
> Fred

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

 - Merge remote-tracking branch 'upstream/lworld' into 8376814
 - Update test to cover NULLABLE_NON_ATOMIC_FLAT

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2040/files
  - new: https://git.openjdk.org/valhalla/pull/2040/files/59061a99..8e1374a8

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

  Stats: 222 lines in 17 files changed: 158 ins; 15 del; 49 mod
  Patch: https://git.openjdk.org/valhalla/pull/2040.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2040/head:pull/2040

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

From liach at openjdk.org  Thu Feb  5 14:40:47 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 14:40:47 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
Message-ID: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>

> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...

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

 - Redundant if block per review
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
 - Missed test
 - Rollback breaking change
 - Remove private buffer

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2018/files
  - new: https://git.openjdk.org/valhalla/pull/2018/files/cf3de78c..b58a8b4f

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

  Stats: 15623 lines in 414 files changed: 8566 ins; 3773 del; 3284 mod
  Patch: https://git.openjdk.org/valhalla/pull/2018.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2018/head:pull/2018

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

From thartmann at openjdk.org  Thu Feb  5 15:02:21 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 5 Feb 2026 15:02:21 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
Message-ID: <kwubW4pYG3zYPvQOCwZsMTok6GIitXLce94fOGDASm4=.b6c502c9-d2e1-4c45-9522-38bad7ecdb38@github.com>

On Thu, 5 Feb 2026 14:40:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Redundant if block per review
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Missed test
>  - Rollback breaking change
>  - Remove private buffer

Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2018#pullrequestreview-3757652621

From qamai at openjdk.org  Thu Feb  5 15:16:16 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 5 Feb 2026 15:16:16 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
Message-ID: <OhcLAlsjDhD8bW0f7gJSnvgrqkVRgPQKph8xBcLgsmA=.68cef403-9ba5-4da1-aa09-d38e80da3d54@github.com>

On Thu, 5 Feb 2026 14:40:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Redundant if block per review
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Missed test
>  - Rollback breaking change
>  - Remove private buffer

Marked as reviewed by qamai (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/2018#pullrequestreview-3757738251

From matsaave at openjdk.org  Thu Feb  5 15:19:16 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 5 Feb 2026 15:19:16 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v4]
In-Reply-To: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
Message-ID: <Ud45lW-mzeV4z_M6g5cCpqOd7MDhFEGPOl8T0ZxRLLk=.405abf31-bde5-4761-9d2f-5f8a9744cbbc@github.com>

> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Update comment and fix copyright

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2025/files
  - new: https://git.openjdk.org/valhalla/pull/2025/files/e16f0b0a..e4c7bdc5

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

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

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

From jbhateja at openjdk.org  Thu Feb  5 15:22:34 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Feb 2026 15:22:34 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
Message-ID: <HVwL7Nrwws9J5CTN2yOmtAv-Tf_iAqarCQPpnAoQyJM=.063330f2-3aa1-4196-8946-d1f5587a319a@github.com>

On Thu, 5 Feb 2026 14:40:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Redundant if block per review
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Missed test
>  - Rollback breaking change
>  - Remove private buffer

These two APIs are heavily used in lworld+vector.

With this change it will need significant change on that branch with next merge.

There is currently no way to update @multifield based payload apart from an Unsafe API

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3854329869

From rriggs at openjdk.org  Thu Feb  5 15:23:45 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 5 Feb 2026 15:23:45 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v4]
In-Reply-To: <Ud45lW-mzeV4z_M6g5cCpqOd7MDhFEGPOl8T0ZxRLLk=.405abf31-bde5-4761-9d2f-5f8a9744cbbc@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <Ud45lW-mzeV4z_M6g5cCpqOd7MDhFEGPOl8T0ZxRLLk=.405abf31-bde5-4761-9d2f-5f8a9744cbbc@github.com>
Message-ID: <whtF093jhn1AiK_pVWwHUkfSDyZS6C5rMDsG1HfHDhU=.6ccfb1e7-2974-492a-8272-7f327d5e4d6a@github.com>

On Thu, 5 Feb 2026 15:19:16 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment and fix copyright

Looks good

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2025#pullrequestreview-3757780848

From jbhateja at openjdk.org  Thu Feb  5 15:28:43 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Feb 2026 15:28:43 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
Message-ID: <9DJqGxxtwWGiX4nNukWH2qqztz9vP6PI6aD_lSjhu7E=.bc213591-16f7-4430-8348-3b69d4a863fd@github.com>

On Thu, 5 Feb 2026 14:40:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Redundant if block per review
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Missed test
>  - Rollback breaking change
>  - Remove private buffer

Please refer to our earlier discussion on this
https://github.com/openjdk/valhalla/pull/1688#issuecomment-3640741548

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3854377864

From liach at openjdk.org  Thu Feb  5 15:33:36 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 15:33:36 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <9DJqGxxtwWGiX4nNukWH2qqztz9vP6PI6aD_lSjhu7E=.bc213591-16f7-4430-8348-3b69d4a863fd@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
 <9DJqGxxtwWGiX4nNukWH2qqztz9vP6PI6aD_lSjhu7E=.bc213591-16f7-4430-8348-3b69d4a863fd@github.com>
Message-ID: <B6YP7sKtNSyvGiQNqSLBMweINXtWbfo8PsmRGV6vOP4=.d2999977-0989-4180-818e-104e90b9f122@github.com>

On Thu, 5 Feb 2026 15:26:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Redundant if block per review
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>>  - Missed test
>>  - Rollback breaking change
>>  - Remove private buffer
>
> Please refer to our earlier discussion on this
> https://github.com/openjdk/valhalla/pull/1688#issuecomment-3640741548

Hi @jatin-bhateja, I think you can remove the array restriction for vector types currently present in +vector, and use this "write zero vector to array", "unsafe hack array", and finally "read vector from array" approach as demonstrated in the test updates here.

In addition, we plan to update the multifield to make it less invasive to the other parts of the VM - we really just need an updated layout and one accessor maybe for compiler interface, we shouldn't change all field name access code in the entirety of hotspot.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3854395010

From qamai at openjdk.org  Thu Feb  5 15:33:37 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 5 Feb 2026 15:33:37 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
Message-ID: <6dhiien3XIzsNInjrug31TgsyoQDnGdyoMOjI1GHd9Y=.8a04f22f-737d-43e9-8c23-afbe355751c0@github.com>

On Thu, 5 Feb 2026 14:40:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Redundant if block per review
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Missed test
>  - Rollback breaking change
>  - Remove private buffer

I think it makes little sense to include in lworld an API that is only used in lworld+vector. So, for now, you can retain this API in lworld+vector only until we can come up with a satisfying design for @multifield.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3854401883

From liach at openjdk.org  Thu Feb  5 15:35:57 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 15:35:57 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
Message-ID: <nSgnJvfULxqkl10MN7Q1t6F4qVkPYlRs5-PdYY2M9vg=.542d2285-4815-4efd-894b-5b8a5564156a@github.com>

On Thu, 5 Feb 2026 14:40:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Redundant if block per review
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Missed test
>  - Rollback breaking change
>  - Remove private buffer

The current goals of lworld is to consolidate for mainline integration; it does not accept particular support for other valhalla experimental branches, not even bworld prototype. Unfortunate as it is, I tried to merge lworld into vector in #1955 and think the current vector prototype does need a revamp, at least for its multifield part, to be less invasive.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3854420239

From jbhateja at openjdk.org  Thu Feb  5 15:39:25 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Feb 2026 15:39:25 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
Message-ID: <ZVbrk4brVwGh8L5-I_w1MNB9JUOI7lpQkuqTCpaOsMY=.5434fac2-0415-4f2d-a7ed-2bcfebe86561@github.com>

On Thu, 5 Feb 2026 14:40:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Redundant if block per review
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Missed test
>  - Rollback breaking change
>  - Remove private buffer

Marked as reviewed by jbhateja (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/2018#pullrequestreview-3757871309

From jbhateja at openjdk.org  Thu Feb  5 15:39:26 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Feb 2026 15:39:26 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <6dhiien3XIzsNInjrug31TgsyoQDnGdyoMOjI1GHd9Y=.8a04f22f-737d-43e9-8c23-afbe355751c0@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
 <6dhiien3XIzsNInjrug31TgsyoQDnGdyoMOjI1GHd9Y=.8a04f22f-737d-43e9-8c23-afbe355751c0@github.com>
Message-ID: <V6NrQey12wrgTr9-g5YZNaPrK5JEBFd8Q-fbUkkyWkQ=.1add31e6-6cb5-4629-8248-7de95622cb8f@github.com>

On Thu, 5 Feb 2026 15:30:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I think it makes little sense to include in lworld an API that is only used in lworld+vector. So, for now, you can retain this API in lworld+vector only until we can come up with a satisfying design for @multifield.

That seems workable for now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3854435634

From dlsmith at openjdk.org  Thu Feb  5 16:24:22 2026
From: dlsmith at openjdk.org (Dan Smith)
Date: Thu, 5 Feb 2026 16:24:22 GMT
Subject: RFR: Support preview features in libraries [v2]
In-Reply-To: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
References: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
Message-ID: <rDH0xaBwkRunN-BIUI6Ubmx-3aNf1wWzDe5jzjyc1lo=.a3545544-2d04-44bf-a510-3c7ddbc64692@github.com>

> Always allow preview class files, compile standard libs with --enable-preview

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  change Referencies record to use static method

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2037/files
  - new: https://git.openjdk.org/valhalla/pull/2037/files/fc719e7d..dad14789

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

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

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

From liach at openjdk.org  Thu Feb  5 16:26:16 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 16:26:16 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v4]
In-Reply-To: <Ud45lW-mzeV4z_M6g5cCpqOd7MDhFEGPOl8T0ZxRLLk=.405abf31-bde5-4761-9d2f-5f8a9744cbbc@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <Ud45lW-mzeV4z_M6g5cCpqOd7MDhFEGPOl8T0ZxRLLk=.405abf31-bde5-4761-9d2f-5f8a9744cbbc@github.com>
Message-ID: <kZeNGkysN4hltdCp_GYNBTdqNrbX4e6C7AbZaCPtEs8=.bba1b761-8fcf-46e3-ac14-df3acc8e8899@github.com>

On Thu, 5 Feb 2026 15:19:16 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment and fix copyright

Good

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2025#pullrequestreview-3758133695

From fparain at openjdk.org  Thu Feb  5 16:46:07 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 5 Feb 2026 16:46:07 GMT
Subject: [lworld] RFR: 8375306: [lworld] Investigate alternatives to
 flatArrayOopDresc::obj_at implementation
Message-ID: <jCvwdmmm4o5HT3IP9ja9TXv1rFggbJNXT2rVFS0J1RU=.db743fcf-f852-4e03-917e-310580a72952@github.com>

First batch of changes to remove potentially dangerous calls to objArrayOopDesc::obj_at().
Changes are more extensive than intended. In most cases, code modifications consist in using a refArrayOop type instead of a objArrayOop type, because most of the arrays the JVM deals with for its own purpose are always reference arrays (because they are arrays of identity type elements). The patch also adds a new API allowing the VM to request the allocation of a reference array.
Code dealing with user provided arrays must be ready to handle exceptions when accessing objArrays.

This is a short term fix, fixing a few bugs, and trying to make the code more robust using the meta-data types. For the long term, a better solution is needed. Accesses to both arrays and fields are becoming more and more complex because of the introduction of flattening, multiple layouts, additional properties. Forcing enforcement at each access would be expensive and wasteful, as the JVM usually operates on well-known objects or arrays. But because of the increasing complexity, having a way to quickly check the validity of an access would help making the VM code more robust.

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

Commit messages:
 - Revert foreign methods signature changes
 - Foreign API and other fixes
 - CI fixes
 - More fixes in serviceability code
 - More fixes of array types
 - Initial push to enforce use of refArray by the JVM

Changes: https://git.openjdk.org/valhalla/pull/2033/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2033&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375306
  Stats: 227 lines in 44 files changed: 62 ins; 23 del; 142 mod
  Patch: https://git.openjdk.org/valhalla/pull/2033.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2033/head:pull/2033

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

From liach at openjdk.org  Thu Feb  5 17:01:39 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 17:01:39 GMT
Subject: [lworld] RFR: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer [v2]
In-Reply-To: <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
 <Ul8qCsehKc02VmAziSMoRb0qEi8iVWRBlKXHQS4TglA=.b7f09de1-8b12-4c82-a656-3d69dd71bec5@github.com>
Message-ID: <1VvbFDXIxKknp630id-08bB7zAV9RnSp-n5-EoIAow4=.651bf1a2-c923-420c-917e-a38adf06bd4f@github.com>

On Thu, 5 Feb 2026 14:40:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Redundant if block per review
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/buffer-removal
>  - Missed test
>  - Rollback breaking change
>  - Remove private buffer

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2018#issuecomment-3854918538

From dlsmith at openjdk.org  Thu Feb  5 17:07:01 2026
From: dlsmith at openjdk.org (Dan Smith)
Date: Thu, 5 Feb 2026 17:07:01 GMT
Subject: RFR: Support preview features in libraries [v3]
In-Reply-To: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
References: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
Message-ID: <oASXsMig2pJEJ_vYog8AM0yrdrxv008QcjxqActRS9c=.463a3ae5-a17d-40f5-bc53-481db4cd3e44@github.com>

> Always allow preview class files, compile standard libs with --enable-preview

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  langtools test fixes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2037/files
  - new: https://git.openjdk.org/valhalla/pull/2037/files/dad14789..1a094540

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

  Stats: 9 lines in 3 files changed: 5 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/2037.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2037/head:pull/2037

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

From liach at openjdk.org  Thu Feb  5 17:01:40 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 17:01:40 GMT
Subject: [lworld] Integrated: 8373375: [lworld] Remove
 Unsafe.make/finishPrivateBuffer
In-Reply-To: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
References: <1qzQ6M10s3amsRYVO5Xx_Ydxo3RQOTZ_9PZ5wvygdVs=.75684bce-8768-4be6-84d6-64bd70f4c994@github.com>
Message-ID: <tXm0ujdIbXnvzqZVmxWJf7ScPCkzKJBsD7sZ8z97ats=.6110ea76-695a-45fb-bad5-866c4eaffd69@github.com>

On Mon, 2 Feb 2026 23:34:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> WIP, replacing make/finishPrivateBuffer with flat array operations, yet to figure out how to ensure UseArrayFlattening is always on...

This pull request has now been integrated.

Changeset: f3aa9c9c
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f3aa9c9c9c8ff25c75aed960939dcd46248a04f0
Stats:     466 lines in 14 files changed: 6 ins; 422 del; 38 mod

8373375: [lworld] Remove Unsafe.make/finishPrivateBuffer

Reviewed-by: thartmann, qamai, jbhateja

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

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

From darcy at openjdk.org  Thu Feb  5 17:08:12 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 17:08:12 GMT
Subject: RFR: [type-classes] 8377195: Add prototype complex type using
 polar coordinates [v2]
In-Reply-To: <Zlj6Kah0_aOrKTJLgUudla7ihd0o8ehRaIs2DsvcwW4=.54b71ea1-018d-4b31-840d-0d8cfc46ce76@github.com>
References: <Zlj6Kah0_aOrKTJLgUudla7ihd0o8ehRaIs2DsvcwW4=.54b71ea1-018d-4b31-840d-0d8cfc46ce76@github.com>
Message-ID: <-6nQalgjCXkCkjDwlEQjN4hT1hOMuti8XhK5yCM4CS8=.7f8c0c2a-13a7-4925-8cb1-c6d29c94a865@github.com>

> Adding a second flavor of complex numbers with bi-directional conversions.
> 
> Also included Numerical witnesses on both flavors of complex.
> 
> For now, removing the deprecation annotations to make use in jshell less verbose.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Doc cleanup.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2046/files
  - new: https://git.openjdk.org/valhalla/pull/2046/files/b5e67460..10766f2b

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

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

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

From liach at openjdk.org  Thu Feb  5 17:09:37 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 17:09:37 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest [v2]
In-Reply-To: <pdYB9t2zlDFHNONan1ugVNPDxb56nFMt9qN3CNcHbOw=.d7c31bbb-f701-438c-91db-766888db54fa@github.com>
References: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>
 <pdYB9t2zlDFHNONan1ugVNPDxb56nFMt9qN3CNcHbOw=.d7c31bbb-f701-438c-91db-766888db54fa@github.com>
Message-ID: <Ff8CUK9Pw0-17Iigp8QXVlRjTSfcRNqC5v0Zs69-grg=.8cabc629-837f-4ecf-a82b-5b90555fc6d3@github.com>

On Wed, 4 Feb 2026 19:01:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When we read a class file and decode the access flag, we should use the class file's version to decode the flag, so we won't get spurious SUPER and IDENTITY mismatches.
>
> 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 three additional commits since the last revision:
> 
>  - Fix version parse bug, improve coverage
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/accessflags-pass-cffv
>  - 8366270

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2036#issuecomment-3854916490

From liach at openjdk.org  Thu Feb  5 17:09:39 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 17:09:39 GMT
Subject: [lworld] Integrated: 8366270: [lworld] Fix ClassFile AccessFlagsTest
In-Reply-To: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>
References: <lFEFX_NMV9zF-YePAID4W2aPFEbw6zoUhQ80GuOPNuM=.9774602d-53f0-4ea3-8b9b-46f3f364c8fa@github.com>
Message-ID: <h3Kidwtvn0SCCYHoHk4DOHWbqjdXrtZrNaxXuMcZ980=.32626845-e6f9-4f31-b870-76c93395e97b@github.com>

On Wed, 4 Feb 2026 16:37:49 GMT, Chen Liang <liach at openjdk.org> wrote:

> When we read a class file and decode the access flag, we should use the class file's version to decode the flag, so we won't get spurious SUPER and IDENTITY mismatches.

This pull request has now been integrated.

Changeset: fd8d64e6
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/fd8d64e6b42f4d5d990f08e9f248a45ef6346bc5
Stats:     110 lines in 7 files changed: 63 ins; 3 del; 44 mod

8366270: [lworld] Fix ClassFile AccessFlagsTest

Reviewed-by: vromero

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

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

From dlsmith at openjdk.org  Thu Feb  5 17:09:39 2026
From: dlsmith at openjdk.org (Dan Smith)
Date: Thu, 5 Feb 2026 17:09:39 GMT
Subject: Integrated: Support preview features in libraries
In-Reply-To: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
References: <Y4pM98NwBHpwgXaVSFAx8SxcM7Z-aQzagSXD0qnHdkE=.21208fde-e9f6-4f21-999e-fa34cd6dfd31@github.com>
Message-ID: <Kd4Z2Jzt0_rqQMaZykcv7Efm1tZ5HLfb1XIg2pIA7HA=.ddbb3a88-28cf-4891-8e97-969819fa2945@github.com>

On Wed, 4 Feb 2026 16:44:19 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Always allow preview class files, compile standard libs with --enable-preview

This pull request has now been integrated.

Changeset: 013c6aef
Author:    Dan Smith <dlsmith at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/013c6aefa3609dd4993b19d8c84f832bedb77e01
Stats:     26 lines in 10 files changed: 8 ins; 2 del; 16 mod

Support preview features in libraries

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

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

From darcy at openjdk.org  Thu Feb  5 17:14:04 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 17:14:04 GMT
Subject: RFR: 8376223: Add modeling interfaces for algebraic structures:
 groups, rings, and fields
In-Reply-To: <uWFCklZfaLhyoLysg_fE3v0soYR0j95PuMpBBHt6CK0=.1fb174f5-c3a8-4821-b7f6-2d5ca1c9a5d4@github.com>
References: <uWFCklZfaLhyoLysg_fE3v0soYR0j95PuMpBBHt6CK0=.1fb174f5-c3a8-4821-b7f6-2d5ca1c9a5d4@github.com>
Message-ID: <u2LKzXr6vV5giXoJ8YZdmhNIBlqRlqiQ0R_S1Pesmjc=.fa750ba3-1d68-4e11-a258-e97e5a009ec0@github.com>

On Fri, 23 Jan 2026 19:50:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First cut at adding modeling interfaces for the algebraic structures of rings, groups, and fields.

Thanks for the good discussions. For now, I'm going to close to PR. I added the diff as an attachment to the bug to checkpoint the design in case this topic is revisited in the future.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1957#issuecomment-3855008037

From darcy at openjdk.org  Thu Feb  5 17:18:42 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 17:18:42 GMT
Subject: Withdrawn: 8376223: Add modeling interfaces for algebraic structures:
 groups, rings, and fields
In-Reply-To: <uWFCklZfaLhyoLysg_fE3v0soYR0j95PuMpBBHt6CK0=.1fb174f5-c3a8-4821-b7f6-2d5ca1c9a5d4@github.com>
References: <uWFCklZfaLhyoLysg_fE3v0soYR0j95PuMpBBHt6CK0=.1fb174f5-c3a8-4821-b7f6-2d5ca1c9a5d4@github.com>
Message-ID: <oDrIDlhgRY7fMHoDQLpv4LsM1sxqG6LJTWOe8RSMTGQ=.23ed133a-a93c-4e88-b4da-8c2e9449f1c6@github.com>

On Fri, 23 Jan 2026 19:50:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First cut at adding modeling interfaces for the algebraic structures of rings, groups, and fields.

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.org  Thu Feb  5 17:24:20 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 17:24:20 GMT
Subject: Integrated: [type-classes] 8377195: Add prototype complex type using
 polar coordinates
In-Reply-To: <Zlj6Kah0_aOrKTJLgUudla7ihd0o8ehRaIs2DsvcwW4=.54b71ea1-018d-4b31-840d-0d8cfc46ce76@github.com>
References: <Zlj6Kah0_aOrKTJLgUudla7ihd0o8ehRaIs2DsvcwW4=.54b71ea1-018d-4b31-840d-0d8cfc46ce76@github.com>
Message-ID: <1zkJHQQogtuUqoFemZ67EK-VfStkYd7GAsa5Sb2jnz8=.835c99a8-ee6a-4e1e-a5c6-40d6203556f3@github.com>

On Thu, 5 Feb 2026 06:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Adding a second flavor of complex numbers with bi-directional conversions.
> 
> Also included Numerical witnesses on both flavors of complex.
> 
> For now, removing the deprecation annotations to make use in jshell less verbose.

This pull request has now been integrated.

Changeset: 2687ded0
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2687ded0219014965f9af7c16f08bd2fde4bcf86
Stats:     530 lines in 2 files changed: 521 ins; 3 del; 6 mod

[type-classes] 8377195: Add prototype complex type using polar coordinates

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

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

From forax at openjdk.org  Thu Feb  5 17:47:56 2026
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 5 Feb 2026 17:47:56 GMT
Subject: RFR: 8376223: Add modeling interfaces for algebraic structures:
 groups, rings, and fields
In-Reply-To: <wgqZVcuLi6NALBMkWy5BhZNOkqthAfyAHFcwZAvUeGQ=.5aab63f6-a494-465f-8919-d05069b5b10f@github.com>
References: <uWFCklZfaLhyoLysg_fE3v0soYR0j95PuMpBBHt6CK0=.1fb174f5-c3a8-4821-b7f6-2d5ca1c9a5d4@github.com>
 <0LMZ7Spcarin__B3vZO2pW-kmq3etinttMHUHckpQwQ=.d0ddfc5e-a113-4fe3-8320-25acd6080dd7@github.com>
 <wgqZVcuLi6NALBMkWy5BhZNOkqthAfyAHFcwZAvUeGQ=.5aab63f6-a494-465f-8919-d05069b5b10f@github.com>
Message-ID: <p_xSLGVocWz4OBEelX7Z1oS_PmL0LkbMpfZTLwQ5ONk=.14894516-5a9d-4288-8f75-425a838deac4@github.com>

On Sat, 24 Jan 2026 19:00:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> (As a reference point, way back when Pascal included the size of an array as part of its type and this complicated many useful tasks like, say, writing library routines that accepted arrays of any size.)

We may want to add wildcard/erasure, so the landscape can be different than your Pascal days.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1957#issuecomment-3855182689

From darcy at openjdk.org  Thu Feb  5 18:27:44 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 18:27:44 GMT
Subject: RFR: [type-classes] 8377311: Add equals and hashCode methods for
 UnsignedInt and ExactInt
Message-ID: <znxvrjBEBXjrUFqubdZaClZ52FbV9kaWjT8CCHi4PCs=.f11b6d11-0d1a-48fe-8746-fbf59a034104@github.com>

Add accidentally omitted methods.

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

Commit messages:
 - 8377311: Add equals and hashCode methods for UnsignedInt and ExactInt

Changes: https://git.openjdk.org/valhalla/pull/2050/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2050&range=00
  Stats: 42 lines in 2 files changed: 40 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/2050.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2050/head:pull/2050

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

From darcy at openjdk.org  Thu Feb  5 18:53:54 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 18:53:54 GMT
Subject: Integrated: [type-classes] 8377311: Add equals and hashCode methods
 for UnsignedInt and ExactInt
In-Reply-To: <znxvrjBEBXjrUFqubdZaClZ52FbV9kaWjT8CCHi4PCs=.f11b6d11-0d1a-48fe-8746-fbf59a034104@github.com>
References: <znxvrjBEBXjrUFqubdZaClZ52FbV9kaWjT8CCHi4PCs=.f11b6d11-0d1a-48fe-8746-fbf59a034104@github.com>
Message-ID: <DDDDWdEhIKCeaY7gmDhXKVgOAd4vswbQWlTCQfn9QnE=.792dfd43-83ec-4d19-a5c2-a17c0c6c085a@github.com>

On Thu, 5 Feb 2026 18:21:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add accidentally omitted methods.

This pull request has now been integrated.

Changeset: d4663b4c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d4663b4caa5515281972072f4111911066b9a73e
Stats:     42 lines in 2 files changed: 40 ins; 0 del; 2 mod

[type-classes] 8377311: Add equals and hashCode methods for UnsignedInt and ExactInt

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

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

From matsaave at openjdk.org  Thu Feb  5 19:22:45 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 5 Feb 2026 19:22:45 GMT
Subject: [lworld] RFR: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP [v4]
In-Reply-To: <whtF093jhn1AiK_pVWwHUkfSDyZS6C5rMDsG1HfHDhU=.6ccfb1e7-2974-492a-8272-7f327d5e4d6a@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
 <Ud45lW-mzeV4z_M6g5cCpqOd7MDhFEGPOl8T0ZxRLLk=.405abf31-bde5-4761-9d2f-5f8a9744cbbc@github.com>
 <whtF093jhn1AiK_pVWwHUkfSDyZS6C5rMDsG1HfHDhU=.6ccfb1e7-2974-492a-8272-7f327d5e4d6a@github.com>
Message-ID: <1T2glzII15mT85M60DkGGh0e5yOzJo6GGOjkVyQW5o4=.ba5849fb-a9c2-4bdd-b857-ba2408b8c43d@github.com>

On Thu, 5 Feb 2026 15:20:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment and fix copyright
>
> Looks good

Thanks for the reviews and corrections @RogerRiggs @liach and @fparain!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2025#issuecomment-3855719788

From matsaave at openjdk.org  Thu Feb  5 19:22:47 2026
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 5 Feb 2026 19:22:47 GMT
Subject: [lworld] Integrated: 8367935: [lworld] Rename ACC_STRICT in the JVM
 according to strict fields JEP
In-Reply-To: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
References: <5t4JuuwiFGerfO22IRu5zuhN52TRFl0a5Rma2NaVThs=.b6529835-d7a6-478f-9dc3-51faae34f961@github.com>
Message-ID: <joODV-NRUK2GAzhXFxvrEmyNTFg2FkSOWehj5w6s980=.a90aa59d-acae-4f77-b57e-aa26e2ee105e@github.com>

On Tue, 3 Feb 2026 20:21:48 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Strict initialization is now indicated with the access flag `ACC_STRICT_INIT` in the JVMS and the VM implementation should follow. `ACC_STRICT` is currently used as a method modifier for strict floating-point semantics so this refactor will help to make both modifiers distinct. VM and Java code has to be updated to use the correct modifier. Verified with tier x-y tests.

This pull request has now been integrated.

Changeset: 81c54fb7
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/81c54fb7a1dc55c28f7d48f00a95e2137e338310
Stats:     34 lines in 10 files changed: 5 ins; 0 del; 29 mod

8367935: [lworld] Rename ACC_STRICT in the JVM according to strict fields JEP

Reviewed-by: fparain, liach, rriggs

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

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

From liach at openjdk.org  Thu Feb  5 19:39:59 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 19:39:59 GMT
Subject: [lworld] RFR: 8376103: [lworld] Basic Zero support [v3]
In-Reply-To: <4qp3Dh1-SmlwCaXvUI61EI5ahRa_tlg5RHR_kGBi--E=.e5977a1b-0988-425f-9976-0832c3e9d8ec@github.com>
References: <cMhg_6DEG3p6LtO-M2KaX7X-o8BVvmccLZ13evyTXF8=.7257fd42-4474-41d5-855f-28d203aed19c@github.com>
 <4qp3Dh1-SmlwCaXvUI61EI5ahRa_tlg5RHR_kGBi--E=.e5977a1b-0988-425f-9976-0832c3e9d8ec@github.com>
Message-ID: <CnbREf9Ts9onfI9A6gAUpAljyZtg0Ge0_aJSFYHhKTM=.008da932-d0d4-4ec7-835d-189db629df38@github.com>

On Wed, 4 Feb 2026 09:16:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> On the way to stabilizing Valhalla for inclusion into mainline, we want to have Zero builds at least buildable and lightly runnable, e.g. for creating their own CDS archives. There is likely to be some bugtail to pass all the tests, this is out of scope for this basic support. We need to pull some fixes from mainline to make this work going smoother.
>> 
>> I have also enabled Zero Hotspot build in GHA back to keep it buildable.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 zero fastdebug, build works
>>  - [x] Linux x86_64 zero fastdebug, bootcycle build works
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'lworld' into JDK-8376103-zero-support
>  - Merge branch 'lworld' into JDK-8376103-zero-support
>  - Build works
>  - Basic Zero build is working

Sure, let's go with it.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1943#issuecomment-3855799508

From shade at openjdk.org  Thu Feb  5 19:40:00 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Feb 2026 19:40:00 GMT
Subject: [lworld] Integrated: 8376103: [lworld] Basic Zero support
In-Reply-To: <cMhg_6DEG3p6LtO-M2KaX7X-o8BVvmccLZ13evyTXF8=.7257fd42-4474-41d5-855f-28d203aed19c@github.com>
References: <cMhg_6DEG3p6LtO-M2KaX7X-o8BVvmccLZ13evyTXF8=.7257fd42-4474-41d5-855f-28d203aed19c@github.com>
Message-ID: <Fw2tMJmnrcRXiitoofCeRrvS6KJFi_XkMm7mOs6s7-o=.dc5d0a1d-5a18-4994-809b-75e677cdab0b@github.com>

On Thu, 22 Jan 2026 13:49:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> On the way to stabilizing Valhalla for inclusion into mainline, we want to have Zero builds at least buildable and lightly runnable, e.g. for creating their own CDS archives. There is likely to be some bugtail to pass all the tests, this is out of scope for this basic support. We need to pull some fixes from mainline to make this work going smoother.
> 
> I have also enabled Zero Hotspot build in GHA back to keep it buildable.
> 
> Additional testing:
>  - [x] Linux x86_64 zero fastdebug, build works
>  - [x] Linux x86_64 zero fastdebug, bootcycle build works

This pull request has now been integrated.

Changeset: e7d07ae0
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e7d07ae0581d9ec437f44bc252ad3c038939b42c
Stats:     49 lines in 7 files changed: 29 ins; 1 del; 19 mod

8376103: [lworld] Basic Zero support

Reviewed-by: coleenp

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

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

From darcy at openjdk.org  Thu Feb  5 19:48:00 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 19:48:00 GMT
Subject: RFR: [type-classes] 8377322: Upgrade Float16 to use operators
Message-ID: <Qv5OQemjfMRGdbLN7CT4iKEKT959xtiw9vcRg7FqBAM=.bf89956b-846b-4bea-88d9-2995f99c963c@github.com>

Add witnesses and associated tests to Float16.

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

Commit messages:
 - 8377322: Upgrade Float16 to use operators

Changes: https://git.openjdk.org/valhalla/pull/2051/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2051&range=00
  Stats: 190 lines in 3 files changed: 185 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/2051.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2051/head:pull/2051

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

From forax at univ-mlv.fr  Thu Feb  5 20:34:10 2026
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 5 Feb 2026 21:34:10 +0100 (CET)
Subject: Orderable vs Ordering
Message-ID: <2131608947.34666897.1770323650911.JavaMail.zimbra@univ-eiffel.fr>

Hello,
taking a look to the type-class interfaces in java.lang, 
I think Orderable is not the right name, and will confuse people.

The suffix "able" is usually used to describe the type itself, Iterable, Closeable,
but here what we want is to describe is a witness which is outside and express a relation between two types.

For me, Comparator can be the name of a witness while Comparable can not.

So i'm voting for Ordering instead of "Orderable" but I'm not a native speaker so there is perhaps a better name.

Also if you agree, the following line
  https://github.com/openjdk/valhalla/blob/type-classes/src/java.base/share/classes/java/lang/Orderable.java#L42
should be @see Comparator.

regards,
R?mi

From liach at openjdk.org  Thu Feb  5 20:37:33 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 20:37:33 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <2NRIu9vF9ys8wPTBCxVh28mi-KuP6usNs6jWiVA4NZE=.4e6c1ca0-f67c-41a4-b3da-b138d9cc6354@github.com>
References: <2NRIu9vF9ys8wPTBCxVh28mi-KuP6usNs6jWiVA4NZE=.4e6c1ca0-f67c-41a4-b3da-b138d9cc6354@github.com>
Message-ID: <Mz5w1x7tPsQhmxoO_abAn2HML-HjnF74S-elYv1OBCM=.305c6c28-d353-421d-ba6e-edaa26c3bcfc@github.com>

> Merge now to fix conflicts from ACC_STRICT_INIT renames.

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

 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into bworld-merge-lworld
 - [bworld] fixing regression tests
   
   Reviewed-by: liach
 - [bworld] javac crash for abstract methods with null restricted arguments
   
   Reviewed-by: liach
 - [bworld] BasicAccessFlags and JavaBaseCheckSince failing
 - JVM detect null checked flag
   
   Reviewed-by: vromero
 - Merge lworld
 - Merge lworld
 - Remove redundant null checks
   
   Reviewed-by: mcimadamore
 - add javac and javap support for the ACC_NULL_CHECKED flag
   
   Reviewed-by: liach
 - Merge lworld
 - ... and 120 more: https://git.openjdk.org/valhalla/compare/e7d07ae0...2baf0d95

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

Changes: https://git.openjdk.org/valhalla/pull/2052/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2052&range=01
  Stats: 8196 lines in 130 files changed: 7801 ins; 95 del; 300 mod
  Patch: https://git.openjdk.org/valhalla/pull/2052.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2052/head:pull/2052

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

From liach at openjdk.org  Thu Feb  5 20:37:35 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 20:37:35 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <2NRIu9vF9ys8wPTBCxVh28mi-KuP6usNs6jWiVA4NZE=.4e6c1ca0-f67c-41a4-b3da-b138d9cc6354@github.com>
References: <2NRIu9vF9ys8wPTBCxVh28mi-KuP6usNs6jWiVA4NZE=.4e6c1ca0-f67c-41a4-b3da-b138d9cc6354@github.com>
Message-ID: <HfnBNw_TWGsbs2vEMofZfQaCELC8yCu7XEzv-zNqEtw=.7f3e3b48-5d6a-414b-ac75-a25ddb044c9b@github.com>

On Thu, 5 Feb 2026 19:53:45 GMT, Chen Liang <liach at openjdk.org> wrote:

> Merge now to fix conflicts from ACC_STRICT_INIT renames.

This pull request has now been integrated.

Changeset: e96209ff
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e96209ffab845f4f48b4a02bef6350e9003b136e
Stats:     752 lines in 43 files changed: 183 ins; 428 del; 141 mod

Merge lworld

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

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

From liach at openjdk.org  Thu Feb  5 20:44:17 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 20:44:17 GMT
Subject: RFR: Merge bworld
Message-ID: <qsVbiVesxY-3513UEbkBpAMuqgeMdnotd1-l97rond8=.9a3acc48-5a47-4192-aa1d-59c00b99f91f@github.com>

Merge the JVM parsing of ACC_NULL_CHECKED and the bang fix for native/abstract methods.

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

Commit messages:
 - Merge branch 'bworld' of https://github.com/openjdk/valhalla into bworld-apis-merge
 - Merge lworld
 - 8376103: [lworld] Basic Zero support
 - 8367935: [lworld] Rename ACC_STRICT in the JVM according to strict fields JEP
 - 8366270: [lworld] Fix ClassFile AccessFlagsTest
 - 8373375: [lworld] Remove Unsafe.make/finishPrivateBuffer
 - 8376213: [lworld] C2: assert(is_InlineType()) failed: invalid node class: Phi/LoadP/DecodeN
 - 8376733: [lworld] Inconsistent result of Invoke::declared_type triggers assert in profiling
 - [bworld] fixing regression tests
 - [bworld] javac crash for abstract methods with null restricted arguments
 - ... and 7 more: https://git.openjdk.org/valhalla/compare/013c6aef...06efd5a4

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

Changes: https://git.openjdk.org/valhalla/pull/2053/files
  Stats: 1049 lines in 69 files changed: 326 ins; 504 del; 219 mod
  Patch: https://git.openjdk.org/valhalla/pull/2053.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2053/head:pull/2053

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

From liach at openjdk.org  Thu Feb  5 20:49:06 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 20:49:06 GMT
Subject: RFR: Merge bworld [v2]
In-Reply-To: <qsVbiVesxY-3513UEbkBpAMuqgeMdnotd1-l97rond8=.9a3acc48-5a47-4192-aa1d-59c00b99f91f@github.com>
References: <qsVbiVesxY-3513UEbkBpAMuqgeMdnotd1-l97rond8=.9a3acc48-5a47-4192-aa1d-59c00b99f91f@github.com>
Message-ID: <sdm00mcGRveh6xtUdsn_iTa2SMqWwPWSYdxozhRiG6M=.79c205c3-fd30-4be9-abee-7bfe2cb355e8@github.com>

> Merge the JVM parsing of ACC_NULL_CHECKED and the bang fix for native/abstract methods.

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 two additional commits since the last revision:

 - Merge branch 'bworld' of https://github.com/openjdk/valhalla into bworld-apis-merge
 - Support preview features in libraries

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2053/files
  - new: https://git.openjdk.org/valhalla/pull/2053/files/06efd5a4..06efd5a4

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/2053.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2053/head:pull/2053

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

From liach at openjdk.org  Thu Feb  5 20:49:07 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 20:49:07 GMT
Subject: RFR: Merge bworld
In-Reply-To: <qsVbiVesxY-3513UEbkBpAMuqgeMdnotd1-l97rond8=.9a3acc48-5a47-4192-aa1d-59c00b99f91f@github.com>
References: <qsVbiVesxY-3513UEbkBpAMuqgeMdnotd1-l97rond8=.9a3acc48-5a47-4192-aa1d-59c00b99f91f@github.com>
Message-ID: <nVUnkd-VWCs_d9BvY1xMPFTsz3cXBJ2bAPjt_Qb9sIo=.8a7823ec-edae-42e2-a5c0-d04e8d041663@github.com>

On Thu, 5 Feb 2026 20:37:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Merge the JVM parsing of ACC_NULL_CHECKED and the bang fix for native/abstract methods.

Merging to allow further prototyping.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2053#issuecomment-3856093594

From liach at openjdk.org  Thu Feb  5 20:49:09 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 20:49:09 GMT
Subject: Integrated: Merge bworld
In-Reply-To: <qsVbiVesxY-3513UEbkBpAMuqgeMdnotd1-l97rond8=.9a3acc48-5a47-4192-aa1d-59c00b99f91f@github.com>
References: <qsVbiVesxY-3513UEbkBpAMuqgeMdnotd1-l97rond8=.9a3acc48-5a47-4192-aa1d-59c00b99f91f@github.com>
Message-ID: <CNStMXKsXlaZD5yGdo_ICkvHc6LEGSyj3InVZ3mLJak=.d5ea3ddc-013c-4271-98cf-631fcfdf1b86@github.com>

On Thu, 5 Feb 2026 20:37:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Merge the JVM parsing of ACC_NULL_CHECKED and the bang fix for native/abstract methods.

This pull request has now been integrated.

Changeset: 3daec2c3
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3daec2c36e8729c5acde6fd86b4922b91bbbfec2
Stats:     1049 lines in 69 files changed: 326 ins; 504 del; 219 mod

Merge bworld

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

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

From coleenp at openjdk.org  Thu Feb  5 21:07:39 2026
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Feb 2026 21:07:39 GMT
Subject: [lworld] RFR: 8375306: [lworld] Investigate alternatives to
 flatArrayOopDresc::obj_at implementation
In-Reply-To: <jCvwdmmm4o5HT3IP9ja9TXv1rFggbJNXT2rVFS0J1RU=.db743fcf-f852-4e03-917e-310580a72952@github.com>
References: <jCvwdmmm4o5HT3IP9ja9TXv1rFggbJNXT2rVFS0J1RU=.db743fcf-f852-4e03-917e-310580a72952@github.com>
Message-ID: <f0libjClgWo6cTCqZLgdyrRPFZN0bGMvXK8Tk_bwJVU=.5a3fb443-0b5c-4779-81e8-dfe2bd78085c@github.com>

On Wed, 4 Feb 2026 14:41:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> First batch of changes to remove potentially dangerous calls to objArrayOopDesc::obj_at().
> Changes are more extensive than intended. In most cases, code modifications consist in using a refArrayOop type instead of a objArrayOop type, because most of the arrays the JVM deals with for its own purpose are always reference arrays (because they are arrays of identity type elements). The patch also adds a new API allowing the VM to request the allocation of a reference array.
> Code dealing with user provided arrays must be ready to handle exceptions when accessing objArrays.
> 
> This is a short term fix, fixing a few bugs, and trying to make the code more robust using the meta-data types. For the long term, a better solution is needed. Accesses to both arrays and fields are becoming more and more complex because of the introduction of flattening, multiple layouts, additional properties. Forcing enforcement at each access would be expensive and wasteful, as the JVM usually operates on well-known objects or arrays. But because of the increasing complexity, having a way to quickly check the validity of an access would help making the VM code more robust.

> flatArrayOopDresc::obj_at

Typo: there's an extra 'r' in the name.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2033#issuecomment-3856197663

From brian.goetz at oracle.com  Thu Feb  5 21:22:02 2026
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 5 Feb 2026 21:22:02 +0000
Subject: Orderable vs Ordering
In-Reply-To: <2131608947.34666897.1770323650911.JavaMail.zimbra@univ-eiffel.fr>
References: <2131608947.34666897.1770323650911.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <1A43AF06-9E9F-46D1-AA8D-6354E266333D@oracle.com>

This is all super speculative.  Naming discussions are premature; many of these won?t even be proposed in the end.  

Sent from my iPad

> On Feb 5, 2026, at 9:34?PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ?Hello,
> taking a look to the type-class interfaces in java.lang,
> I think Orderable is not the right name, and will confuse people.
> 
> The suffix "able" is usually used to describe the type itself, Iterable, Closeable,
> but here what we want is to describe is a witness which is outside and express a relation between two types.
> 
> For me, Comparator can be the name of a witness while Comparable can not.
> 
> So i'm voting for Ordering instead of "Orderable" but I'm not a native speaker so there is perhaps a better name.
> 
> Also if you agree, the following line
>  https://github.com/openjdk/valhalla/blob/type-classes/src/java.base/share/classes/java/lang/Orderable.java#L42
> should be @see Comparator.
> 
> regards,
> R?mi

From fparain at openjdk.org  Thu Feb  5 21:31:12 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 5 Feb 2026 21:31:12 GMT
Subject: [lworld] RFR: 8377243: [lworld]
 HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound
In-Reply-To: <aKWrKal5eVRcM0iVf-Excgi6u3YHUr2KUXG7YWod8xk=.a734ad6b-7287-4384-97c5-ca889882fd20@github.com>
References: <aKWrKal5eVRcM0iVf-Excgi6u3YHUr2KUXG7YWod8xk=.a734ad6b-7287-4384-97c5-ca889882fd20@github.com>
Message-ID: <yHW9rBBNRBm_H_qdTOXDvTIsUI6FD9Nf3uknvZLivzo=.4083ff4e-5eb3-42de-8e82-7b7de5aac8fd@github.com>

On Thu, 5 Feb 2026 14:32:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `IS_DEST_UNINITIALIZED ` is ment to signal to the GC that you cannot read the contents of the field as it is uninitialized. This is used by the compiler which have strict control over its safepoints.
> 
> The MemAllocator in the runtime has no such guarantees, and will clear all oop fields before handing the allocated object. These objects can have been seen by the GC and even tenured before the call  `HeapAccess<IS_DEST_UNINITIALIZED>::value_copy`. This is unsound. ZGC for example could miss young to old edges if the destination object had been tenured.
> 
> I propose we remove these and always use `HeapAccess<>::value_copy`. The behaviour will be the same for value objects which do not contain oops, and correct of values which contains oops. There is the potential in the future to add something along the lines of `IS_DEST_NULL` to provide more static information to the GC to optimise the barriers on. However the gain here is probably negligible.

Looks good to me.
Thank you for the detailed explanation.

Fred

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2048#pullrequestreview-3759553679

From fparain at openjdk.org  Thu Feb  5 21:36:16 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 5 Feb 2026 21:36:16 GMT
Subject: [lworld] RFR: 8377242: [lworld] Remove _has_inlined_fields member
 from ClassFileParser
In-Reply-To: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
References: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
Message-ID: <nFkuOj9w8SGT8XHOZA4y9Alxxa0xU0VbGLQITSmwd5k=.e8bc9a60-35b6-4d6e-a2be-4cb4adfdf5ad@github.com>

On Thu, 5 Feb 2026 13:07:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This PR removes the redundant `ClassFileParser::_has_inlined_fields` member from ClassFileParser. The value stored in `_has_inlined_fields` is derived directly from `FieldLayoutInfo` and is only used for a getter. Since `ClassFileParser` already retains this in `_layout_info`, a separate duplicate member is unnecessary. With this change, the getter returns the value directly from the stored `FieldLayoutInfo`, removing the extra member while preserving existing behavior.
> 
> Testing:
> - Tier 1

LGTM

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2047#pullrequestreview-3759571642

From coleenp at openjdk.org  Thu Feb  5 22:28:35 2026
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Feb 2026 22:28:35 GMT
Subject: [lworld] RFR: 8365722: [lworld] SA tests fail with Array Klass rework
Message-ID: <1Bej4PhAKa2nDtobdadDk8x5hU1sTuetgMp1r1xsJPE=.5759a4e6-fa5e-40e4-a4de-a4e697c264f8@github.com>

This change adds RefArrayKlass.java to SA so that the class is recognized, and updates the ProblemList.

Tested with tier1-3.

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

Commit messages:
 - Update ProblemList.

Changes: https://git.openjdk.org/valhalla/pull/2055/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365722
  Stats: 121 lines in 6 files changed: 62 ins; 50 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/2055.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2055/head:pull/2055

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

From liach at openjdk.org  Thu Feb  5 22:59:33 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 22:59:33 GMT
Subject: RFR: [bworld] Fix iterating arg types for null checks
Message-ID: <MM0RSVDYN8DG0JN0Ol0A_jEDlEPd347Zg4p9i21V740=.a820ebf1-88b4-40db-abb2-30b03dedda70@github.com>

Discovered this bug when prototyping core reflection. Without this fix, the test fails with:

testRuntimeChecks/src/Test/Test.java:7: error: bad operand type int for unary operator '<*nullrestrictedchk*>'
        t.work(args[0], a, b);
                        ^
testRuntimeChecks/src/Test/Test.java:7: error: bad operand type boolean for unary operator '<*nullrestrictedchk*>'
        t.work(args[0], a, b);
                           ^
Note: testRuntimeChecks/src/Test/Test.java uses preview features of Java SE 27.
Note: Recompile with -Xlint:preview for details.
2 errors

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

Commit messages:
 - [bworld] Fix iterating arg types for null checks

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

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

From liach at openjdk.org  Thu Feb  5 23:23:24 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 23:23:24 GMT
Subject: RFR: [type-classes] 8377322: Upgrade Float16 to use operators
In-Reply-To: <Qv5OQemjfMRGdbLN7CT4iKEKT959xtiw9vcRg7FqBAM=.bf89956b-846b-4bea-88d9-2995f99c963c@github.com>
References: <Qv5OQemjfMRGdbLN7CT4iKEKT959xtiw9vcRg7FqBAM=.bf89956b-846b-4bea-88d9-2995f99c963c@github.com>
Message-ID: <ntYEjwo-FULdFHpVEtVIDkumbTSoy4596cACS2uHbfQ=.f4af876d-35f4-4cbf-86b0-9d2511ea9796@github.com>

On Thu, 5 Feb 2026 19:40:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add witnesses and associated tests to Float16.

Looks fine

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2051#pullrequestreview-3759917028

From liach at openjdk.org  Thu Feb  5 23:26:53 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Feb 2026 23:26:53 GMT
Subject: [lworld] RFR: 8377328: [lworld] Remove legacy readme and classfile
 constants
Message-ID: <Rakhr9OT5uv9M7J4JgH8BC2xhCAbs6bQxHit7oJz5hc=.bbd19c39-9500-4514-9243-9af0ee5a61bf@github.com>

There is a legacy src/readme and legacy ACC_PRIMITIVE and Q descriptor left in classfile_constants.h.template. Let's remove all of them.

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

Commit messages:
 - Remove obsolete constants and readme

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

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

From darcy at openjdk.org  Thu Feb  5 23:36:44 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Feb 2026 23:36:44 GMT
Subject: Integrated: [type-classes] 8377322: Upgrade Float16 to use operators
In-Reply-To: <Qv5OQemjfMRGdbLN7CT4iKEKT959xtiw9vcRg7FqBAM=.bf89956b-846b-4bea-88d9-2995f99c963c@github.com>
References: <Qv5OQemjfMRGdbLN7CT4iKEKT959xtiw9vcRg7FqBAM=.bf89956b-846b-4bea-88d9-2995f99c963c@github.com>
Message-ID: <ZObRmgxZi3QB7slt4rogVcKLvq4oZ-mRIc0-X1dEtdc=.a44d8f91-65d7-4ade-90ea-ef7ba1fd039d@github.com>

On Thu, 5 Feb 2026 19:40:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add witnesses and associated tests to Float16.

This pull request has now been integrated.

Changeset: 249c2632
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/249c2632b08fb4a606d3d97b59796a5afc0541fe
Stats:     190 lines in 3 files changed: 185 ins; 0 del; 5 mod

[type-classes] 8377322: Upgrade Float16 to use operators

Reviewed-by: liach

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

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

From vromero at openjdk.org  Fri Feb  6 00:29:02 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 6 Feb 2026 00:29:02 GMT
Subject: RFR: [bworld] Emit lint warnings if overriding method does not have
 same nullability
Message-ID: <qLv8Dx7vUYLx4p1kUhslY0u34ixQQ-uRouyGmnb5fcM=.1d915bb9-f51b-451d-a428-d835ec6d73fb@github.com>

emit a lint warning for cases like:

class Test {
    String! m(String s) { return ""; }
}
class Sub extends Test {
    @Override
    String m(String s) { return null; }
}

or:

class Test {
    String m(String! s) { return ""; }
}
class Sub extends Test {
    @Override
    String m(String s) { return null; }
}

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

Commit messages:
 - [bworld] Emit lint warnings if overriding method does not have same nullability

Changes: https://git.openjdk.org/valhalla/pull/2058/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2058&range=00
  Stats: 100 lines in 5 files changed: 91 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/2058.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2058/head:pull/2058

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

From liach at openjdk.org  Fri Feb  6 00:44:44 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Feb 2026 00:44:44 GMT
Subject: RFR: [bworld] Emit lint warnings if overriding method does not
 have same nullability
In-Reply-To: <qLv8Dx7vUYLx4p1kUhslY0u34ixQQ-uRouyGmnb5fcM=.1d915bb9-f51b-451d-a428-d835ec6d73fb@github.com>
References: <qLv8Dx7vUYLx4p1kUhslY0u34ixQQ-uRouyGmnb5fcM=.1d915bb9-f51b-451d-a428-d835ec6d73fb@github.com>
Message-ID: <-_cwuRH-vLmCiIxR_lIEVsmhKvf3trhR1V4QKEfsAK8=.7a858e72-4e6b-4699-b22f-44c7aab64bc2@github.com>

On Fri, 6 Feb 2026 00:23:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> emit a lint warning for cases like:
> 
> class Test {
>     String! m(String s) { return ""; }
> }
> class Sub extends Test {
>     @Override
>     String m(String s) { return null; }
> }
> 
> or:
> 
> class Test {
>     String m(String! s) { return ""; }
> }
> class Sub extends Test {
>     @Override
>     String m(String s) { return null; }
> }

test/langtools/tools/javac/nullability/NullabilityCompilationTests.java line 319:

> 317:                                 class Sub extends Test {
> 318:                                     @Override
> 319:                                     String m(String s) { return null; }

I think this should be no-warning, instead we should emit warning if Test.m does not have ! but Sub.m has, meaning test.m(null) call will fail on Sub.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2058#discussion_r2771741078

From liach at openjdk.org  Fri Feb  6 04:51:22 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Feb 2026 04:51:22 GMT
Subject: RFR: Show null restriction markers in javadoc. [v2]
In-Reply-To: <kz-Mi3C1fA3X-T8foXnANWJVEZq-4sHH_pllvJ7RROw=.9ecccaba-210c-4cd4-9ff9-d951e0bae426@github.com>
References: <Pa5Y24GszVe25Q7ydZutpgcFB02DqEGJnv3hb2Uc3l4=.57979cef-ddd1-4ced-ab14-d18dfcbc1e9d@github.com>
 <kz-Mi3C1fA3X-T8foXnANWJVEZq-4sHH_pllvJ7RROw=.9ecccaba-210c-4cd4-9ff9-d951e0bae426@github.com>
Message-ID: <SWlMPARb34DBeR_M6W_KnGKDQNPVtWjR4RpNFmSHHKU=.d426dbbb-0408-42f9-b225-11f6c91f7536@github.com>

On Wed, 4 Feb 2026 13:57:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adds null markers inside generated javadoc like this:
>> <img width="1144" height="528" alt="null-markers-javadoc" src="https://github.com/user-attachments/assets/b97736ff-f240-4c88-b874-32a8f7c8743c" />
>> 
>> Not sure if this is the ideal UI, and this is the best way to do implement it.
>> 
>> I didn't add tests yet, given the representation may change with experience.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a test.

@lahodaj Uses of type variables can be null-marked. Should we render those marks too?

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

PR Comment: https://git.openjdk.org/valhalla/pull/2022#issuecomment-3857950603

From aboldtch at openjdk.org  Fri Feb  6 07:58:58 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 6 Feb 2026 07:58:58 GMT
Subject: [lworld] RFR: 8377243: [lworld]
 HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound
 [v2]
In-Reply-To: <aKWrKal5eVRcM0iVf-Excgi6u3YHUr2KUXG7YWod8xk=.a734ad6b-7287-4384-97c5-ca889882fd20@github.com>
References: <aKWrKal5eVRcM0iVf-Excgi6u3YHUr2KUXG7YWod8xk=.a734ad6b-7287-4384-97c5-ca889882fd20@github.com>
Message-ID: <EYIPJjMQk2GGx1_Rr7P-RblE5s3jDbQyCK-QCVU9Pfo=.0562e5a3-e2df-4cbf-9586-72957fb29fa9@github.com>

> `IS_DEST_UNINITIALIZED ` is ment to signal to the GC that you cannot read the contents of the field as it is uninitialized. This is used by the compiler which have strict control over its safepoints.
> 
> The MemAllocator in the runtime has no such guarantees, and will clear all oop fields before handing the allocated object. These objects can have been seen by the GC and even tenured before the call  `HeapAccess<IS_DEST_UNINITIALIZED>::value_copy`. This is unsound. ZGC for example could miss young to old edges if the destination object had been tenured.
> 
> I propose we remove these and always use `HeapAccess<>::value_copy`. The behaviour will be the same for value objects which do not contain oops, and correct of values which contains oops. There is the potential in the future to add something along the lines of `IS_DEST_NULL` to provide more static information to the GC to optimise the barriers on. However the gain here is probably negligible.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'upstream_valhalla/lworld' into JDK-8377243
 - 8377243: [lworld] HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound

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

Changes: https://git.openjdk.org/valhalla/pull/2048/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2048&range=01
  Stats: 22 lines in 4 files changed: 0 ins; 12 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/2048.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2048/head:pull/2048

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

From thartmann at openjdk.org  Fri Feb  6 08:54:13 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 6 Feb 2026 08:54:13 GMT
Subject: [lworld] RFR: 8374024: [lworld] Follow-up cleanups from JDK-8228361
Message-ID: <_1Y1IqP6hN8HCjARb1nkWyz-_ODMd2x88BFWwQvPjks=.7b5596d9-2a02-4882-99a7-c4f4ed4a0d08@github.com>

Cleanups suggested by @mhaessig in https://github.com/openjdk/valhalla/pull/1823.

Thanks,
Tobias

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

Commit messages:
 - 8374024: [lworld] Follow-up cleanups from JDK-8228361

Changes: https://git.openjdk.org/valhalla/pull/2059/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2059&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374024
  Stats: 132 lines in 4 files changed: 61 ins; 51 del; 20 mod
  Patch: https://git.openjdk.org/valhalla/pull/2059.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2059/head:pull/2059

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

From cnorrbin at openjdk.org  Fri Feb  6 11:47:48 2026
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 6 Feb 2026 11:47:48 GMT
Subject: [lworld] RFR: 8377242: [lworld] Remove _has_inlined_fields member
 from ClassFileParser
In-Reply-To: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
References: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
Message-ID: <kmrLoZEaOSswy9OoYSM9gq0O_AOW5cU1ZRqdyehrEtM=.20b32dd1-dbb4-4fe5-99de-f65de0dbb342@github.com>

On Thu, 5 Feb 2026 13:07:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This PR removes the redundant `ClassFileParser::_has_inlined_fields` member from ClassFileParser. The value stored in `_has_inlined_fields` is derived directly from `FieldLayoutInfo` and is only used for a getter. Since `ClassFileParser` already retains this in `_layout_info`, a separate duplicate member is unnecessary. With this change, the getter returns the value directly from the stored `FieldLayoutInfo`, removing the extra member while preserving existing behavior.
> 
> Testing:
> - Tier 1

Thank you all for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/2047#issuecomment-3859975913

From duke at openjdk.org  Fri Feb  6 11:47:48 2026
From: duke at openjdk.org (duke)
Date: Fri, 6 Feb 2026 11:47:48 GMT
Subject: [lworld] RFR: 8377242: [lworld] Remove _has_inlined_fields member
 from ClassFileParser
In-Reply-To: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
References: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
Message-ID: <UNAAxoxwZ-cskRj8KWKlhdqmyu7ZJupkZkdPR8Cidb8=.e8927fc1-e990-4851-9373-621ed0327c88@github.com>

On Thu, 5 Feb 2026 13:07:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This PR removes the redundant `ClassFileParser::_has_inlined_fields` member from ClassFileParser. The value stored in `_has_inlined_fields` is derived directly from `FieldLayoutInfo` and is only used for a getter. Since `ClassFileParser` already retains this in `_layout_info`, a separate duplicate member is unnecessary. With this change, the getter returns the value directly from the stored `FieldLayoutInfo`, removing the extra member while preserving existing behavior.
> 
> Testing:
> - Tier 1

@caspernorrbin 
Your change (at version 5a8ead254159b540d9e2116c57b7a1100fe19bf4) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2047#issuecomment-3859980436

From cnorrbin at openjdk.org  Fri Feb  6 12:16:41 2026
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 6 Feb 2026 12:16:41 GMT
Subject: [lworld] Integrated: 8377242: [lworld] Remove _has_inlined_fields
 member from ClassFileParser
In-Reply-To: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
References: <fBuiR_8Uf4Ai-pRx7hkqKLiS9SMhtijSmScjBbJ2cA8=.9308a254-1416-4833-87cd-ffc22e2e09de@github.com>
Message-ID: <7OGdUEMHRnFKs6uj8lkHWlJQTUBtqrpvWZ6cqzTv4fE=.208af599-ff2a-4331-bd4a-97f71c3a75a8@github.com>

On Thu, 5 Feb 2026 13:07:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This PR removes the redundant `ClassFileParser::_has_inlined_fields` member from ClassFileParser. The value stored in `_has_inlined_fields` is derived directly from `FieldLayoutInfo` and is only used for a getter. Since `ClassFileParser` already retains this in `_layout_info`, a separate duplicate member is unnecessary. With this change, the getter returns the value directly from the stored `FieldLayoutInfo`, removing the extra member while preserving existing behavior.
> 
> Testing:
> - Tier 1

This pull request has now been integrated.

Changeset: 83ef4858
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Committer: Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/83ef4858dcbce1e1c1a01dbac24bb4332ecf8d9a
Stats:     4 lines in 2 files changed: 0 ins; 3 del; 1 mod

8377242: [lworld] Remove _has_inlined_fields member from ClassFileParser

Reviewed-by: phubner, liach, fparain

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

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

From stefank at openjdk.org  Fri Feb  6 12:27:16 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Feb 2026 12:27:16 GMT
Subject: [lworld] RFR: 8375306: [lworld] Investigate alternatives to
 flatArrayOopDresc::obj_at implementation
In-Reply-To: <jCvwdmmm4o5HT3IP9ja9TXv1rFggbJNXT2rVFS0J1RU=.db743fcf-f852-4e03-917e-310580a72952@github.com>
References: <jCvwdmmm4o5HT3IP9ja9TXv1rFggbJNXT2rVFS0J1RU=.db743fcf-f852-4e03-917e-310580a72952@github.com>
Message-ID: <QCaiQp5GvQgW6PNwNpditZW3gJsiqp73sn6y36kODIc=.c8993378-1f9f-4333-ac17-6f7b940065ab@github.com>

On Wed, 4 Feb 2026 14:41:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> First batch of changes to remove potentially dangerous calls to objArrayOopDesc::obj_at().

Just to be clear, this PR is just a sub-set of all usages of obj_at and obj_at_put that needs to be fixed?

While looking through the patch I saw two things that I'd want to see if we can clean up:

1) You always pass down `ArrayKlass::ArrayProperties::DEFAULT` to `new_refArray`, so that can be confined to that function:

https://github.com/stefank/valhalla/commit/6770b92d77cd3e9a5e04e9abc2e33eb3f4005206

2) You've introduced a `force_refarray` parameter and passes in `false` in a lot of places without being explicit about what the argument signifies. This makes the call-sites harder to read, so I first wanted to suggest that you change this to `false /* force_refarray */`. However, then I figured that it really would be nice if we could completely get rid of that parameter instead. This is what I came up with:

https://github.com/stefank/valhalla/commit/68a5601904b27c59e3e62d4b1971b6a80c3b888b

Could you take a look and see if that makes sense?

The branch for this is here:
https://github.com/stefank/valhalla/tree/refarray_factory_stefank

and diff against lworld:
https://github.com/openjdk/valhalla/compare/lworld...stefank:valhalla:refarray_factory_stefank

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

PR Comment: https://git.openjdk.org/valhalla/pull/2033#issuecomment-3860139337

From coleenp at openjdk.org  Fri Feb  6 12:47:47 2026
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Feb 2026 12:47:47 GMT
Subject: [lworld] RFR: 8366820: [lworld] TestClassLoaderStatsEvent.java test
 failure
Message-ID: <xdzGZJGUixTn33Oor9R3WLa52P1VFs-V21elI4Hywwo=.0b69acb9-58a4-4e7b-9199-c8d56927328d@github.com>

This change excludes all but ObjArrayKlass in class listing, since the caller cares about Java types, not Metadata.  JFR calls this code.  This uses similar code and comment to JVMTI changes.

Tested with tier1-4.

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

Commit messages:
 - Update test/jdk/ProblemList.txt
 - Update test/jdk/ProblemList.txt
 - Merge branch 'lworld' into jfr
 - 8366820: [lworld] TestClassLoaderStatsEvent.java test failure

Changes: https://git.openjdk.org/valhalla/pull/2054/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366820
  Stats: 17 lines in 2 files changed: 13 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/2054.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2054/head:pull/2054

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

From coleenp at openjdk.org  Fri Feb  6 12:47:48 2026
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Feb 2026 12:47:48 GMT
Subject: [lworld] RFR: 8366820: [lworld] TestClassLoaderStatsEvent.java
 test failure
In-Reply-To: <xdzGZJGUixTn33Oor9R3WLa52P1VFs-V21elI4Hywwo=.0b69acb9-58a4-4e7b-9199-c8d56927328d@github.com>
References: <xdzGZJGUixTn33Oor9R3WLa52P1VFs-V21elI4Hywwo=.0b69acb9-58a4-4e7b-9199-c8d56927328d@github.com>
Message-ID: <vllI9lLCROYlZSBgwrbfE4I3ygfNi9dNXNPlGzz4pEw=.870c8f82-6c30-4dff-95fa-e0f87a3ccc1e@github.com>

On Thu, 5 Feb 2026 20:59:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change excludes all but ObjArrayKlass in class listing, since the caller cares about Java types, not Metadata.  JFR calls this code.  This uses similar code and comment to JVMTI changes.
> 
> Tested with tier1-4.

test/jdk/ProblemList.txt line 807:

> 805: java/net/CookieHandler/B6644726.java                            8365811 generic-all
> 806: 
> 807: jdk/classfile/AccessFlagsTest.java 8366270 generic-all

Suggestion:

test/jdk/ProblemList.txt line 807:

> 805: java/net/CookieHandler/B6644726.java                            8365811 generic-all
> 806: 
> 807: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2054#discussion_r2773952559
PR Review Comment: https://git.openjdk.org/valhalla/pull/2054#discussion_r2773954454

From coleenp at openjdk.org  Fri Feb  6 12:49:58 2026
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Feb 2026 12:49:58 GMT
Subject: [lworld] RFR: 8365722: [lworld] SA tests fail with Array Klass
 rework [v2]
In-Reply-To: <1Bej4PhAKa2nDtobdadDk8x5hU1sTuetgMp1r1xsJPE=.5759a4e6-fa5e-40e4-a4de-a4e697c264f8@github.com>
References: <1Bej4PhAKa2nDtobdadDk8x5hU1sTuetgMp1r1xsJPE=.5759a4e6-fa5e-40e4-a4de-a4e697c264f8@github.com>
Message-ID: <WgrQe3qq2_usWwmH80cBq-TXpcMnQ33IXJL6WPoC1AE=.548f338f-5ad2-4516-8bcb-a796d150a046@github.com>

> This change adds RefArrayKlass.java to SA so that the class is recognized, and updates the ProblemList.
> 
> Tested with tier1-3.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Move SA tests to enable-preview problem list.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/2055/files
  - new: https://git.openjdk.org/valhalla/pull/2055/files/37867cd0..bc8e881b

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

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

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

From duke at openjdk.org  Fri Feb  6 12:51:56 2026
From: duke at openjdk.org (David Beaumont)
Date: Fri, 6 Feb 2026 12:51:56 GMT
Subject: [lworld] RFR: 8377362: [lworld] CLONE - Update ModuleReaderTest to
 JUnit prior to making changes
Message-ID: <xwu5aqP5FXRgunSnOIW8CXDo4rd-iyaVR9ipAws_SMc=.8c4ccc5f-4ea9-40ce-ab3a-83f18ee62ceb@github.com>

Updated legacy TestNG asserts to JUnit and added useful context to help debugging when assertions fail.

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

Commit messages:
 - cloned test

Changes: https://git.openjdk.org/valhalla/pull/2061/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2061&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377362
  Stats: 105 lines in 1 file changed: 6 ins; 55 del; 44 mod
  Patch: https://git.openjdk.org/valhalla/pull/2061.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2061/head:pull/2061

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

From rriggs at openjdk.org  Fri Feb  6 12:51:58 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 6 Feb 2026 12:51:58 GMT
Subject: [lworld] RFR: 8377362: [lworld] CLONE - Update ModuleReaderTest to
 JUnit prior to making changes
In-Reply-To: <xwu5aqP5FXRgunSnOIW8CXDo4rd-iyaVR9ipAws_SMc=.8c4ccc5f-4ea9-40ce-ab3a-83f18ee62ceb@github.com>
References: <xwu5aqP5FXRgunSnOIW8CXDo4rd-iyaVR9ipAws_SMc=.8c4ccc5f-4ea9-40ce-ab3a-83f18ee62ceb@github.com>
Message-ID: <IQlu3_Kcw8T7IwmyfK6GgP0NbxgfW9DGyA-q-s-gdDY=.7b27fece-cf69-46bf-9174-fffc7ff848d3@github.com>

On Fri, 6 Feb 2026 12:43:39 GMT, David Beaumont <duke at openjdk.org> wrote:

> Updated legacy TestNG asserts to JUnit and added useful context to help debugging when assertions fail.

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2061#pullrequestreview-3762917360

From aboldtch at openjdk.org  Fri Feb  6 14:01:42 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 6 Feb 2026 14:01:42 GMT
Subject: [lworld] RFR: 8377243: [lworld]
 HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound
 [v2]
In-Reply-To: <EYIPJjMQk2GGx1_Rr7P-RblE5s3jDbQyCK-QCVU9Pfo=.0562e5a3-e2df-4cbf-9586-72957fb29fa9@github.com>
References: <aKWrKal5eVRcM0iVf-Excgi6u3YHUr2KUXG7YWod8xk=.a734ad6b-7287-4384-97c5-ca889882fd20@github.com>
 <EYIPJjMQk2GGx1_Rr7P-RblE5s3jDbQyCK-QCVU9Pfo=.0562e5a3-e2df-4cbf-9586-72957fb29fa9@github.com>
Message-ID: <rw8KXEp2MMa_1MZ-cqmCUuf-xIsXSa7hV44HomxeG8Y=.e119214c-cba3-4c4e-82af-bbdc1e7d60dd@github.com>

On Fri, 6 Feb 2026 07:58:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> `IS_DEST_UNINITIALIZED ` is ment to signal to the GC that you cannot read the contents of the field as it is uninitialized. This is used by the compiler which have strict control over its safepoints.
>> 
>> The MemAllocator in the runtime has no such guarantees, and will clear all oop fields before handing the allocated object. These objects can have been seen by the GC and even tenured before the call  `HeapAccess<IS_DEST_UNINITIALIZED>::value_copy`. This is unsound. ZGC for example could miss young to old edges if the destination object had been tenured.
>> 
>> I propose we remove these and always use `HeapAccess<>::value_copy`. The behaviour will be the same for value objects which do not contain oops, and correct of values which contains oops. There is the potential in the future to add something along the lines of `IS_DEST_NULL` to provide more static information to the GC to optimise the barriers on. However the gain here is probably negligible.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream_valhalla/lworld' into JDK-8377243
>  - 8377243: [lworld] HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound

Thanks for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2048#issuecomment-3860637153

From aboldtch at openjdk.org  Fri Feb  6 14:01:44 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 6 Feb 2026 14:01:44 GMT
Subject: [lworld] Integrated: 8377243: [lworld]
 HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound
In-Reply-To: <aKWrKal5eVRcM0iVf-Excgi6u3YHUr2KUXG7YWod8xk=.a734ad6b-7287-4384-97c5-ca889882fd20@github.com>
References: <aKWrKal5eVRcM0iVf-Excgi6u3YHUr2KUXG7YWod8xk=.a734ad6b-7287-4384-97c5-ca889882fd20@github.com>
Message-ID: <pdelLuTETkS0TnJzup8BlD2lvkMot_eo7w6hk4SY_l8=.fcbb83cd-d3f0-4fcd-b3bd-205477eddbec@github.com>

On Thu, 5 Feb 2026 14:32:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `IS_DEST_UNINITIALIZED ` is ment to signal to the GC that you cannot read the contents of the field as it is uninitialized. This is used by the compiler which have strict control over its safepoints.
> 
> The MemAllocator in the runtime has no such guarantees, and will clear all oop fields before handing the allocated object. These objects can have been seen by the GC and even tenured before the call  `HeapAccess<IS_DEST_UNINITIALIZED>::value_copy`. This is unsound. ZGC for example could miss young to old edges if the destination object had been tenured.
> 
> I propose we remove these and always use `HeapAccess<>::value_copy`. The behaviour will be the same for value objects which do not contain oops, and correct of values which contains oops. There is the potential in the future to add something along the lines of `IS_DEST_NULL` to provide more static information to the GC to optimise the barriers on. However the gain here is probably negligible.

This pull request has now been integrated.

Changeset: 4518df2c
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4518df2c8d47a42c31cf67977d88652ce5f835c0
Stats:     22 lines in 4 files changed: 0 ins; 12 del; 10 mod

8377243: [lworld] HeapAccess<IS_DEST_UNINITIALIZED>::value_copy uses in the runtime are unsound

Reviewed-by: fparain

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

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

From fparain at openjdk.org  Fri Feb  6 14:22:33 2026
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 6 Feb 2026 14:22:33 GMT
Subject: [lworld] RFR: 8365722: [lworld] SA tests fail with Array Klass
 rework [v2]
In-Reply-To: <WgrQe3qq2_usWwmH80cBq-TXpcMnQ33IXJL6WPoC1AE=.548f338f-5ad2-4516-8bcb-a796d150a046@github.com>
References: <1Bej4PhAKa2nDtobdadDk8x5hU1sTuetgMp1r1xsJPE=.5759a4e6-fa5e-40e4-a4de-a4e697c264f8@github.com>
 <WgrQe3qq2_usWwmH80cBq-TXpcMnQ33IXJL6WPoC1AE=.548f338f-5ad2-4516-8bcb-a796d150a046@github.com>
Message-ID: <hKcauBK9KdkYvFoOebckhOZo9FXCKoXeY_fbx5NCoRk=.d6f04549-8f33-43a3-946e-5fb609b66439@github.com>

On Fri, 6 Feb 2026 12:49:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change adds RefArrayKlass.java to SA so that the class is recognized, and updates the ProblemList.
>> 
>> Tested with tier1-3.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move SA tests to enable-preview problem list.

LGTM

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2055#pullrequestreview-3763377834

From thartmann at openjdk.org  Fri Feb  6 14:34:51 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 6 Feb 2026 14:34:51 GMT
Subject: [lworld] RFR: 8375203: [lworld]
 compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java is slow and
 intermittently times out
Message-ID: <sSQjen0BuR8KoAiAKNJ7x2xUTYVcyltAycgNjP9CZzc=.96d74c20-0771-4cc7-8c23-493284af1d4c@github.com>

The test times out with `-XX:+VerifyOops`, often with AOT class loading. The problem is that it runs with a very large number of iterations and `-XX:+VerifyOops` is slow with C1 compiled code. I reduced the number of iterations and guarded the C1 runs by `@requires vm.flagless`.

Will run testing over the weekend to verify that this is sufficient. 

Thanks,
Tobias

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

Commit messages:
 - 8375203: [lworld] compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java is slow and intermittently times out

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

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

From dfenacci at openjdk.org  Fri Feb  6 14:49:59 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 6 Feb 2026 14:49:59 GMT
Subject: [lworld] RFR: 8374954: [lworld]
 compiler/ciReplay/TestInliningProtectionDomain.java fails with virtual threads
Message-ID: <Ph7IOxQ0nakH3Vql2Hs-2WiNfBB871_ESpmmTHN2kKE=.b648c239-7f46-48db-8e62-bd619a6fb54e@github.com>

# Issue

`compiler/ciReplay/TestInliningProtectionDomain.java` fails with virtual threads because it expects method `bar()` not to be inlined (1 line in the log) but it gets inlined instead (5 lines in the log for `bar()` and the cascade of methods inside `bar()`).

# Cause

`bar()` relies on `java.lang.Thread` not being loaded but the VM seems to be loading it early on with virtual threads enabled. Apparently this happens because JTreg uses a _Virtual ThreadFactory_ to create virtual threads and this references the `Thread` class and make it resolve early. So, when C2 compiles `ProtectionDomainTestNoOtherCompilationPrivate::test()`, `Thread` is already resolved and the `bar()` inline succeeds.

# Fix

To fix this we can rely on another non-virtual-thread-sensitive `java.lang` class to be returned instead of `Thread`, e.g. `Record`.

# Testing
Tier 1-3+

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

Commit messages:
 - JDK-8374954: copyright year
 - JDK-8374954: add new line
 - Merge branch 'lworld' into JDK-8374954
 - JDK-8374954: [lworld] compiler/ciReplay/TestInliningProtectionDomain.java fails with virtual threads

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

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