From weijun at openjdk.org  Thu Jan  1 04:40:00 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Jan 2026 04:40:00 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
Message-ID: <7sRIajvnH0fG2sLvkHlDnAAZYUKQr1S3A7_5gVEIvN0=.d2153bfd-0dd7-4e2a-86fc-aaafbf990476@github.com>

On Tue, 30 Dec 2025 22:37:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite without jextract
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 152:
> 
>> 150:             int out = (int) getpwuid_r.invokeExact(
>> 151:                     tmpUid, resbuf, pwd_buf, GETPW_R_SIZE_MAX, pwd);
>> 152:             if (out != 0 || pwd.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)) {
> 
> The additional `|| pwd.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)` breaks AIX. The included test passes when we remove it and we get the correct username.
> @JoKern65, @varada1110: Do you know why `getpwuid_r` writes nullptr (or nothing) to `result` on a successful query?

First, thank you so much for the experiments.

Here, I think I follow the C checks in the old `Unix.c`:

    if (getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd) == 0 &&
            pwd != NULL) {

How did it run in AIX?

> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 155:
> 
>> 153:                 uid = tmpUid;
>> 154:                 gid = (int)getgid.invokeExact();
>> 155:                 username = null;
> 
> Setting it to `null` will cause `NullPointerException` in the `UnixPrincipal` constructor.

Hmm, maybe this has never happened before. If the username is really not available, we should not add a `UnixPrincipal`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2656083411
PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2656083377

From aboldtch at openjdk.org  Fri Jan  2 04:27:48 2026
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Jan 2026 04:27:48 GMT
Subject: RFR: 8371346: ZGC: Flexible heap base selection [v4]
In-Reply-To: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>
References: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>
Message-ID: <PNX9ylHzKliKykbKDpeCIWTr8rS9wQF4iCSMwaQdJaM=.ea28cb15-aa07-4d43-abbe-1cc4dbf729c7@github.com>

> ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base.
> 
> Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties.
> 
> With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM.
> 
> This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base.
> 
> I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits.
> 
> The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that.
> 
> On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. 
> 
> There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. 
> 
> Performance testing show no significant differences.
> 
> Testing:
> * GHA
> * Running ZGC tier1-8 on Oracle supported platforms

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 13 commits:

 - Merge tag 'jdk-27+3' into zgc_flexible_heap_base
   
   Added tag jdk-27+3 for changeset 4f283f18
 - Merge tag 'jdk-26+26' into zgc_flexible_heap_base
   
   Added tag jdk-26+26 for changeset 847fbab7
 - Small fixes
 - Merge remote-tracking branch 'upstream_jdk/master' into stefank_review_pr_28161
 - Fixes and cleanups
 - pr/28161_review
 - Merge remote-tracking branch 'upstream/master' into pr/28161
 - Initial Test Implementation
 - Initial implementation flexible heap base
 - Constrain ZAddressOffsetMax correctly when multi-partition fails
 - ... and 3 more: https://git.openjdk.org/jdk/compare/4f283f18...a3a69a11

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

Changes: https://git.openjdk.org/jdk/pull/28161/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=03
  Stats: 2727 lines in 50 files changed: 1886 ins; 631 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/28161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28161/head:pull/28161

PR: https://git.openjdk.org/jdk/pull/28161

From haosun at openjdk.org  Fri Jan  2 09:35:58 2026
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 2 Jan 2026 09:35:58 GMT
Subject: [jdk26] RFR: 8373122: JFR build failure with CDS disabled due to
 -Werror=unused-function after JDK-8365400
In-Reply-To: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
References: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
Message-ID: <2VwhhoYJeHgX4snjrhAmQsQD9kLrIIBhobUh4-M7kNo=.43508487-ee4c-44cd-b31e-fe4624b7da66@github.com>

On Wed, 24 Dec 2025 03:46:49 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e1d81c09](https://github.com/openjdk/jdk/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hao Sun on 23 Dec 2025 and was reviewed by Markus Gr?nlund, Jie Fu and Francesco Andreuzzi.
> 
> Thanks!

Hi, I would appreciate it if you could help review this backport patch again. Thanks.

@fandreuz @DamonFool and @mgronlun

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

PR Comment: https://git.openjdk.org/jdk/pull/28976#issuecomment-3704861285

From fandreuzzi at openjdk.org  Fri Jan  2 11:43:55 2026
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 2 Jan 2026 11:43:55 GMT
Subject: [jdk26] RFR: 8373122: JFR build failure with CDS disabled due to
 -Werror=unused-function after JDK-8365400
In-Reply-To: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
References: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
Message-ID: <PViA0hRxCtqlhllEWkHIVay6Ii2wM0LqT8tCrD4RRIU=.7999b121-ee3b-4e29-8583-a3510c770f4f@github.com>

On Wed, 24 Dec 2025 03:46:49 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e1d81c09](https://github.com/openjdk/jdk/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hao Sun on 23 Dec 2025 and was reviewed by Markus Gr?nlund, Jie Fu and Francesco Andreuzzi.
> 
> Thanks!

Marked as reviewed by fandreuzzi (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28976#pullrequestreview-3622980963

From andrew.m.leonard at ibm.com  Fri Jan  2 11:57:31 2026
From: andrew.m.leonard at ibm.com (Andrew Leonard)
Date: Fri, 2 Jan 2026 11:57:31 +0000
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and
 --with-external-symbols-in-bundles=public - Full symbols location??
Message-ID: <SN6PR1501MB212771319B8AF274BD1C779DCABBA@SN6PR1501MB2127.namprd15.prod.outlook.com>

Hi,

I?m looking to understand the situation on the production of full debug symbols, as we?ve noticed at Adoptium jdk26 JDK images no longer have the full debug symbols where they used to be in the JDK image?
For Temurin release builds we use external symbols (--with-debug-level=release --with-native-debug-symbols=external) and then move the JDK debug info files to a separate debug image tarball, I?m trying to figure what we need to change?
Are the images/symbols folder files full debug files? Should we get them from there instead?
 Thanks



Sent from Outlook for Mac

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20260102/e2802acd/attachment-0001.htm>

From mdoerr at openjdk.org  Fri Jan  2 13:10:54 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 13:10:54 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <7sRIajvnH0fG2sLvkHlDnAAZYUKQr1S3A7_5gVEIvN0=.d2153bfd-0dd7-4e2a-86fc-aaafbf990476@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
 <7sRIajvnH0fG2sLvkHlDnAAZYUKQr1S3A7_5gVEIvN0=.d2153bfd-0dd7-4e2a-86fc-aaafbf990476@github.com>
Message-ID: <fKVrINT5UQC4O_U2Z8N974A7tl1-HXbgRNjeMXnG9bY=.2632a586-1679-40c2-bd93-2350baf4c8b4@github.com>

On Thu, 1 Jan 2026 04:37:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 152:
>> 
>>> 150:             int out = (int) getpwuid_r.invokeExact(
>>> 151:                     tmpUid, resbuf, pwd_buf, GETPW_R_SIZE_MAX, pwd);
>>> 152:             if (out != 0 || pwd.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)) {
>> 
>> The additional `|| pwd.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)` breaks AIX. The included test passes when we remove it and we get the correct username.
>> @JoKern65, @varada1110: Do you know why `getpwuid_r` writes nullptr (or nothing) to `result` on a successful query?
>
> First, thank you so much for the experiments.
> 
> Here, I think I follow the C checks in the old `Unix.c`:
> 
>     if (getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd) == 0 &&
>             pwd != NULL) {
> 
> How did it run in AIX?

The old C code works on AIX. I haven't figured out what causes different behavior with the new code. Note that the new code works on linux on ppc64 (big and little endian).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657691333

From mdoerr at openjdk.org  Fri Jan  2 13:37:57 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 13:37:57 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
Message-ID: <PxesRloLikfstlNxnlwwr1ybe0kSra3mA63AHW_SCbE=.a2c363d0-1deb-4b59-b53f-53c0019ff081@github.com>

On Mon, 22 Dec 2025 14:47:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewrite without jextract

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 83:

> 81:     private static final ValueLayout.OfLong C_LONG
> 82:             = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
> 83: 

These functions are probably always fast and never block, right?
If so, we could use `Linker.Option.critical` to make the calls faster if performance is important.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657727804

From weijun at openjdk.org  Fri Jan  2 13:48:53 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 13:48:53 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <fKVrINT5UQC4O_U2Z8N974A7tl1-HXbgRNjeMXnG9bY=.2632a586-1679-40c2-bd93-2350baf4c8b4@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
 <7sRIajvnH0fG2sLvkHlDnAAZYUKQr1S3A7_5gVEIvN0=.d2153bfd-0dd7-4e2a-86fc-aaafbf990476@github.com>
 <fKVrINT5UQC4O_U2Z8N974A7tl1-HXbgRNjeMXnG9bY=.2632a586-1679-40c2-bd93-2350baf4c8b4@github.com>
Message-ID: <xszXy9Y-chIP9MYeZ3jQmwDuyCaBwb6nNgdEdbOGjlk=.22fbf94d-df8f-413a-8fe3-5d844651ffa0@github.com>

On Fri, 2 Jan 2026 13:08:35 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> First, thank you so much for the experiments.
>> 
>> Here, I think I follow the C checks in the old `Unix.c`:
>> 
>>     if (getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd) == 0 &&
>>             pwd != NULL) {
>> 
>> How did it run in AIX?
>
> The old C code works on AIX. I haven't figured out what causes different behavior with the new code. Note that the new code works on linux on ppc64 (big and little endian).

I tried on both macOS and Linux and `pwd.get(ValueLayout.ADDRESS, 0)` and `resbuf` ended up having the same address. This is consistent to what the doc requires. On the other hand, I tried to pass in a fake uid, the function returned 0 and `pwd` pointed to null. If I ignore the check, my test program crashed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657743731

From weijun at openjdk.org  Fri Jan  2 14:00:54 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 14:00:54 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <PxesRloLikfstlNxnlwwr1ybe0kSra3mA63AHW_SCbE=.a2c363d0-1deb-4b59-b53f-53c0019ff081@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <PxesRloLikfstlNxnlwwr1ybe0kSra3mA63AHW_SCbE=.a2c363d0-1deb-4b59-b53f-53c0019ff081@github.com>
Message-ID: <bD5X3dqYsWjc_3II_a_UaRk7vMGQClxBjS-wwwLrppo=.52298726-143d-49fe-8d96-4df58b22422d@github.com>

On Fri, 2 Jan 2026 13:34:57 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite without jextract
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 83:
> 
>> 81:     private static final ValueLayout.OfLong C_LONG
>> 82:             = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
>> 83: 
> 
> These functions are probably always fast and never block, right?
> If so, we could use `Linker.Option.critical` to make the calls faster if performance is important.

Maybe not necessary, in JAAS one should not login again and again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657759208

From mdoerr at openjdk.org  Fri Jan  2 14:27:00 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 14:27:00 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
Message-ID: <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>

On Mon, 22 Dec 2025 14:47:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewrite without jextract

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 96:

> 94:             .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
> 95:                     FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
> 96:                             C_LONG, C_POINTER));

`C_LONG` looks wrong for 32 bit platforms (arm 32).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657805167

From erik.joelsson at oracle.com  Fri Jan  2 14:33:49 2026
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 2 Jan 2026 06:33:49 -0800
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public - Full symbols location??
In-Reply-To: <SN6PR1501MB212771319B8AF274BD1C779DCABBA@SN6PR1501MB2127.namprd15.prod.outlook.com>
References: <SN6PR1501MB212771319B8AF274BD1C779DCABBA@SN6PR1501MB2127.namprd15.prod.outlook.com>
Message-ID: <ced01dbb-e05a-40a5-8f02-36ac8a1e6837@oracle.com>


On 1/2/26 03:57, Andrew Leonard wrote:
> Hi,
>
> I?m looking to understand the situation on the production of full 
> debug symbols, as we?ve noticed at Adoptium jdk26 JDK images no longer 
> have the full debug symbols where they used to be in the JDK image?
> For Temurin release builds we use external symbols 
> (--with-debug-level=release --with-native-debug-symbols=external) and 
> then move the JDK debug info files to a separate debug image tarball, 
> I?m trying to figure what we need to change?
> Are the images/symbols folder files full debug files? Should we get 
> them from there instead?
> ?Thanks
>
Yes, that is correct. The debug symbols are now only put into the 
symbols image, unless you explicitly configure your build to include 
them in the regular image and bundles using 
`--with-external-symbols-in-bundles=full`.

I would also recommend looking at the `make bundles` or `make 
product-bundles` targets as those will generate the appropriate bundles 
for you, though on Windows they are zip bundles as that's a more 
commonly used packaging format for that platform.

/Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20260102/5f4a75b7/attachment.htm>

From andrew.m.leonard at ibm.com  Fri Jan  2 15:24:39 2026
From: andrew.m.leonard at ibm.com (Andrew Leonard)
Date: Fri, 2 Jan 2026 15:24:39 +0000
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public - Full symbols location??
In-Reply-To: <ced01dbb-e05a-40a5-8f02-36ac8a1e6837@oracle.com>
References: <SN6PR1501MB212771319B8AF274BD1C779DCABBA@SN6PR1501MB2127.namprd15.prod.outlook.com>
 <ced01dbb-e05a-40a5-8f02-36ac8a1e6837@oracle.com>
Message-ID: <SN6PR1501MB2127F2A8333AABD21C42D789CABBA@SN6PR1501MB2127.namprd15.prod.outlook.com>

Thank you Erik, much appreciated


Sent from Outlook for Mac

From: Erik Joelsson <erik.joelsson at oracle.com>
Date: Friday, 2 January 2026 at 14:34
To: Andrew Leonard <andrew.m.leonard at ibm.com>, build-dev at openjdk.org <build-dev at openjdk.org>
Subject: [EXTERNAL] Re: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public - Full symbols location??

This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!99FRGPyyUiXxv7bTLuQqsvS4MGXLa9HzRskApa_-B9he7KLigAVp-kzS8r4TewQkpqab0byXLQ1DqR3-7e5YOIbzVeevK37L_hizFA$>



On 1/2/26 03:57, Andrew Leonard wrote:
Hi,

I?m looking to understand the situation on the production of full debug symbols, as we?ve noticed at Adoptium jdk26 JDK images no longer have the full debug symbols where they used to be in the JDK image?
For Temurin release builds we use external symbols (--with-debug-level=release --with-native-debug-symbols=external) and then move the JDK debug info files to a separate debug image tarball, I?m trying to figure what we need to change?
Are the images/symbols folder files full debug files? Should we get them from there instead?
 Thanks


Yes, that is correct. The debug symbols are now only put into the symbols image, unless you explicitly configure your build to include them in the regular image and bundles using `--with-external-symbols-in-bundles=full`.

I would also recommend looking at the `make bundles` or `make product-bundles` targets as those will generate the appropriate bundles for you, though on Windows they are zip bundles as that's a more commonly used packaging format for that platform.

/Erik

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20260102/53b24029/attachment-0001.htm>

From weijun at openjdk.org  Fri Jan  2 15:28:20 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 15:28:20 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v3]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <Q2DtlfyzOc5GFTZMWsMowij3HdS-78iEoISKZBu6-SI=.7b94def9-f438-431d-8e35-1c7813caa284@github.com>

> Rewrite the native calls with FFM.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  error handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/8c0c7c0b..fa1a511c

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

  Stats: 52 lines in 2 files changed: 34 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931

PR: https://git.openjdk.org/jdk/pull/28931

From weijun at openjdk.org  Fri Jan  2 15:38:59 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 15:38:59 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>
Message-ID: <h1uRSpSClxalHlIBspl3Jgo9SFs8AHA7FaL3CGgUJds=.5ca2823d-38a5-4163-b745-f72ebeed0422@github.com>

On Fri, 2 Jan 2026 14:23:58 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite without jextract
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 96:
> 
>> 94:             .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
>> 95:                     FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
>> 96:                             C_LONG, C_POINTER));
> 
> `C_LONG` looks wrong for 32 bit platforms (arm 32). Note that `size_t` is supported by `canonicalLayouts`.

Do you see 64 bit?
<img width="588" height="306" alt="Screenshot 2026-01-02 at 10 26 20" src="https://github.com/user-attachments/assets/82106d61-27f8-4871-a890-039971665e62" />
There is no arm32 here so I assume it will be the `FallbackLinker`. The size will be returned by a JNI function `ffi_sizeof_long()`. No idea how it could go wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657919123

From mdoerr at openjdk.org  Fri Jan  2 15:58:01 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 15:58:01 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <h1uRSpSClxalHlIBspl3Jgo9SFs8AHA7FaL3CGgUJds=.5ca2823d-38a5-4163-b745-f72ebeed0422@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>
 <h1uRSpSClxalHlIBspl3Jgo9SFs8AHA7FaL3CGgUJds=.5ca2823d-38a5-4163-b745-f72ebeed0422@github.com>
Message-ID: <u3rVZyt8nZiPD77vqe8bCerYiAlxKdBi2M5PHm5C_0k=.fb5dc64b-3151-421d-950b-77c93022dd5d@github.com>

On Fri, 2 Jan 2026 15:35:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 96:
>> 
>>> 94:             .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
>>> 95:                     FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
>>> 96:                             C_LONG, C_POINTER));
>> 
>> `C_LONG` looks wrong for 32 bit platforms (arm 32). Note that `size_t` is supported by `canonicalLayouts`.
>
> Do you see 64 bit?
> <img width="588" height="306" alt="Screenshot 2026-01-02 at 10 26 20" src="https://github.com/user-attachments/assets/82106d61-27f8-4871-a890-039971665e62" />
> There is no arm32 here so I assume it will be the `FallbackLinker`. The size will be returned by a JNI function `ffi_sizeof_long()`. No idea how it could go wrong.

Right, arm32 is using the `FallbackLinker`. `size_t` is mapped here: https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java#L311
which takes it from here:
https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FFIType.java#L59
@bulasevich: You may want to try on arm32.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657948890

From weijun at openjdk.org  Fri Jan  2 16:03:05 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 16:03:05 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <u3rVZyt8nZiPD77vqe8bCerYiAlxKdBi2M5PHm5C_0k=.fb5dc64b-3151-421d-950b-77c93022dd5d@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>
 <h1uRSpSClxalHlIBspl3Jgo9SFs8AHA7FaL3CGgUJds=.5ca2823d-38a5-4163-b745-f72ebeed0422@github.com>
 <u3rVZyt8nZiPD77vqe8bCerYiAlxKdBi2M5PHm5C_0k=.fb5dc64b-3151-421d-950b-77c93022dd5d@github.com>
Message-ID: <hkuwAInnEU3ZSVOUy_212WDcV4QVV2M2Kcio4eop-PE=.fcad3185-e31c-44cb-96d4-e26ad2fc2b56@github.com>

On Fri, 2 Jan 2026 15:53:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Do you see 64 bit?
>> <img width="588" height="306" alt="Screenshot 2026-01-02 at 10 26 20" src="https://github.com/user-attachments/assets/82106d61-27f8-4871-a890-039971665e62" />
>> There is no arm32 here so I assume it will be the `FallbackLinker`. The size will be returned by a JNI function `ffi_sizeof_long()`. No idea how it could go wrong.
>
> Right, arm32 is using the `FallbackLinker`. `size_t` is mapped here: https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java#L311
> which takes it from here:
> https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FFIType.java#L59
> @bulasevich: You may want to try on arm32.

Ah, maybe I should use `canonicalLayouts().get("size_t")`? `jextract` didn't create that entry at the beginning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657965365

From weijun at openjdk.org  Fri Jan  2 16:43:28 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 16:43:28 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v4]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <AoK2nYVNhfCQrJOHmnM0BlnPTXlvxbjD1XKKzU3wIY8=.9736f26f-8f47-43e6-a2e1-cae59e9c273f@github.com>

> Rewrite the native calls with FFM.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  use size_t

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/fa1a511c..05ab387c

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

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

PR: https://git.openjdk.org/jdk/pull/28931

From weijun at openjdk.org  Fri Jan  2 17:00:37 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 17:00:37 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>

> Rewrite the native calls with FFM.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fail early on Windows, and more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/05ab387c..578f1d2e

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

  Stats: 24 lines in 3 files changed: 14 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931

PR: https://git.openjdk.org/jdk/pull/28931

From mdoerr at openjdk.org  Fri Jan  2 23:34:53 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 23:34:53 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
Message-ID: <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>

On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fail early on Windows, and more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154:

> 152:         if (ss.getUsername() != null) {
> 153:             // When getpwuid_r fails, username will not be available.
> 154:             userPrincipal = new UnixPrincipal(ss.getUsername());

With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected).
@JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call):

#include <pwd.h>

__attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd,
                                             char *buf, size_t buflen, struct passwd **result)
{
  return getpwuid_r(uid, pwd, buf, buflen, result);
}

Any idea?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658544971

From weijun at openjdk.org  Sat Jan  3 02:30:55 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 3 Jan 2026 02:30:55 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
Message-ID: <fkpcx_kqqMhSiQeiTHr2d-gDfhin4ONBMKXS7VRZzxE=.ef815873-6916-4c91-ae77-7789b725a1c8@github.com>

On Fri, 2 Jan 2026 23:31:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail early on Windows, and more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154:
> 
>> 152:         if (ss.getUsername() != null) {
>> 153:             // When getpwuid_r fails, username will not be available.
>> 154:             userPrincipal = new UnixPrincipal(ss.getUsername());
> 
> With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected).
> @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call):
> 
> #include <pwd.h>
> 
> __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd,
>                                              char *buf, size_t buflen, struct passwd **result)
> {
>   return getpwuid_r(uid, pwd, buf, buflen, result);
> }
> 
> Any idea?

I somehow think the `size_t buflen` in-between might be the reason. Are they put on the stack or into registers? Is there an alignment issue here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658656686

From weijun at openjdk.org  Sat Jan  3 02:39:56 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 3 Jan 2026 02:39:56 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
Message-ID: <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>

On Fri, 2 Jan 2026 23:31:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail early on Windows, and more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154:
> 
>> 152:         if (ss.getUsername() != null) {
>> 153:             // When getpwuid_r fails, username will not be available.
>> 154:             userPrincipal = new UnixPrincipal(ss.getUsername());
> 
> With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected).
> @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call):
> 
> #include <pwd.h>
> 
> __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd,
>                                              char *buf, size_t buflen, struct passwd **result)
> {
>   return getpwuid_r(uid, pwd, buf, buflen, result);
> }
> 
> Any idea?

Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658665306

From mdoerr at openjdk.org  Sat Jan  3 18:18:57 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 3 Jan 2026 18:18:57 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
Message-ID: <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>

On Sat, 3 Jan 2026 02:37:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154:
>> 
>>> 152:         if (ss.getUsername() != null) {
>>> 153:             // When getpwuid_r fails, username will not be available.
>>> 154:             userPrincipal = new UnixPrincipal(ss.getUsername());
>> 
>> With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected).
>> @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call):
>> 
>> #include <pwd.h>
>> 
>> __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd,
>>                                              char *buf, size_t buflen, struct passwd **result)
>> {
>>   return getpwuid_r(uid, pwd, buf, buflen, result);
>> }
>> 
>> Any idea?
>
> Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`?

No, I don't have `jextract` for AIX, but I think @varada1110 does.
The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.)
I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)!
Calling it through my C wrapper which uses the `size_t` also works as already stated above.
I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2659065739

From weijun at openjdk.org  Sat Jan  3 18:47:54 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 3 Jan 2026 18:47:54 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
Message-ID: <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>

On Sat, 3 Jan 2026 18:15:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`?
>
> No, I don't have `jextract` for AIX, but I think @varada1110 does.
> The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.)
> I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)!
> Calling it through my C wrapper which uses the `size_t` also works as already stated above.
> I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here.

Or I can call this `_posix_getpwuid_r` function in an `if (isAix())` block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2659080243

From serb at openjdk.org  Sun Jan  4 02:20:09 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 4 Jan 2026 02:20:09 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v5]
In-Reply-To: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com>
Message-ID: <XZ7buUettjdNfrLRmQiOp2pCFyepg-bkfZWL3OJueOs=.1459eef6-90ec-404b-8e79-7b9dacc14776@github.com>

On Mon, 10 Nov 2025 22:24:52 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
>> 
>> Summary of code changes:
>> 
>> * Add new warning and associated lint category `"suppression"`
>> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
>> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
>> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
>> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
>> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
>> 
>> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits:
> 
>  - Suppress new unnecessary suppresion warnings created by recent commits.
>  - Merge branch 'master' into JDK-8344159
>  - Merge branch 'master' into JDK-8344159 to fix conflict.
>  - Merge branch 'master' into JDK-8344159 to fix conflict.
>  - Merge branch 'master' into JDK-8344159 to fix conflicts.
>  - Add clarifying comment.
>  - Merge branch 'master' into JDK-8344159
>  - Change inner class name to avoid shadowing superclass name.
>  - Add a couple of code clarification comments.
>  - Refactor test to avoid requiring changes to TestRunner.
>  - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8

Is this PR still active, or is there any ongoing work on it?

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3707541329

From acobbs at openjdk.org  Sun Jan  4 16:27:07 2026
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 4 Jan 2026 16:27:07 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v5]
In-Reply-To: <XZ7buUettjdNfrLRmQiOp2pCFyepg-bkfZWL3OJueOs=.1459eef6-90ec-404b-8e79-7b9dacc14776@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com>
 <XZ7buUettjdNfrLRmQiOp2pCFyepg-bkfZWL3OJueOs=.1459eef6-90ec-404b-8e79-7b9dacc14776@github.com>
Message-ID: <f6pcsITsjd2XSY-8XtQGxc4NraFT4zkL8qsXsPIx5XA=.d6f03fc4-fb53-4e4d-95d5-a47a8d41f4f4@github.com>

On Sun, 4 Jan 2026 02:17:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits:
>> 
>>  - Suppress new unnecessary suppresion warnings created by recent commits.
>>  - Merge branch 'master' into JDK-8344159
>>  - Merge branch 'master' into JDK-8344159 to fix conflict.
>>  - Merge branch 'master' into JDK-8344159 to fix conflict.
>>  - Merge branch 'master' into JDK-8344159 to fix conflicts.
>>  - Add clarifying comment.
>>  - Merge branch 'master' into JDK-8344159
>>  - Change inner class name to avoid shadowing superclass name.
>>  - Add a couple of code clarification comments.
>>  - Refactor test to avoid requiring changes to TestRunner.
>>  - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8
>
> Is this PR still active, or is there any ongoing work on it?

Hi @mrserb,

> Is this PR still active, or is there any ongoing work on it?

Work is completed to the point that it's ready for review, but this is a new feature and as such is lower priority than other changes that are currently being worked on.

In the meantime if you're interested in doing any testing or playing around with it I'd love to hear any feedback. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3708223841

From acobbs at openjdk.org  Sun Jan  4 18:04:45 2026
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 4 Jan 2026 18:04:45 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v6]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <6hvrmK7tyWXAYYeJoCF9jP68LEShyo45T3vo3o7eF2U=.a8c1af86-8025-447e-b531-d195409e3117@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 139 commits:

 - Update copyrights to 2026.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159
 - Suppress new unnecessary suppresion warnings created by recent commits.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Add clarifying comment.
 - ... and 129 more: https://git.openjdk.org/jdk/compare/53824cf2...cad270ed

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=05
  Stats: 1695 lines in 35 files changed: 1492 ins; 49 del; 154 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

PR: https://git.openjdk.org/jdk/pull/25167

From mdoerr at openjdk.org  Mon Jan  5 11:47:23 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Jan 2026 11:47:23 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
Message-ID: <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>

On Sat, 3 Jan 2026 18:45:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> No, I don't have `jextract` for AIX, but I think @varada1110 does.
>> The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.)
>> I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)!
>> Calling it through my C wrapper which uses the `size_t` also works as already stated above.
>> I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here.
>
> Or I can call this `_posix_getpwuid_r` function if `isAix()` is true. Is this enough?
> 
>      private static final MethodHandle getpwuid_r = LINKER
> -            .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
> +            .downcallHandle(SYMBOL_LOOKUP.findOrThrow(
> +                            OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>                      FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
> -                            C_SIZE_T, C_POINTER));
> +                            OperatingSystem.isAix() ? C_INT : C_SIZE_T,
> +                            C_POINTER));

Thank you for taking care of it! I appreciate it. This has worked:

diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
index ee2c5effcf0..3afab6f7974 100644
--- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
+++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
@@ -38,6 +38,8 @@
 import java.lang.invoke.MethodHandle;
 import java.lang.invoke.VarHandle;
 
+import jdk.internal.util.OperatingSystem;
+
 import static java.lang.foreign.MemoryLayout.PathElement.groupElement;
 
 /**
@@ -106,9 +108,9 @@ public class UnixSystem {
             .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getgid"),
                     FunctionDescriptor.of(C_INT));
     private static final MethodHandle getpwuid_r = LINKER
-            .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
+            .downcallHandle(SYMBOL_LOOKUP.findOrThrow(OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
                     FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
-                            C_SIZE_T, C_POINTER));
+                            OperatingSystem.isAix() ? C_INT : C_SIZE_T, C_POINTER));
 
     private static final GroupLayout passwd_layout = MemoryLayout.structLayout(
             C_POINTER.withName("pw_name"),
@@ -136,7 +138,7 @@ public class UnixSystem {
     // sysconf(_SC_GETPW_R_SIZE_MAX) on macOS is 4096 and 1024 on Linux.
     // Not calling sysconf() here because _SC_GETPW_R_SIZE_MAX is different
     // on different platforms.
-    private static final long GETPW_R_SIZE_MAX = 4096L;
+    private static final int GETPW_R_SIZE_MAX = 4096;
 
     /**
      * Instantiate a {@code UnixSystem} and load

Note that `GETPW_R_SIZE_MAX` needs to be an `int` because `long` to `int` conversion would require an explicit cast (probably also for arm32). The other way round works implicitly.

I'd like to have feedback from the AIX experts as well. They may still be on vacation for a couple of days.

We still have a potential problem with the UID parameter. We are using an `int`, but the C code expects an `uint32_t`. Some platforms pass 32 bit values in 64 bit registers and expect a proper extension (zero for unsigned and sign for signed). If the UID becomes larger than INT_MAX, we use sign extend which is wrong.
Not sure of anyone uses so large UIDs and if we could restrict them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661215966

From mcimadamore at openjdk.org  Mon Jan  5 12:28:23 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Jan 2026 12:28:23 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
Message-ID: <YmTo5WCxbz1LGGAcqF4uvO40BE_h140JJd4KgQKdiv0=.55098fd6-44c2-40cb-b7ea-04fa33d0c603@github.com>

On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fail early on Windows, and more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 90:

> 88:             = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("size_t");
> 89: 
> 90:     private static Linker.Option ccs = Linker.Option.captureCallState("errno");

names of static final fields should be capitalized?

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 121:

> 119:             // While we don't need those fields here, the struct needs to be
> 120:             // big enough to avoid buffer overflow when `getpwuid_r` is called.
> 121:             MemoryLayout.sequenceLayout(100, C_CHAR).withName("dummy"));

maybe use a padding layout here? (assuming you don't want clients to access the bytes in `dummy`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661328588
PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661324659

From mcimadamore at openjdk.org  Mon Jan  5 12:34:21 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Jan 2026 12:34:21 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
Message-ID: <PFJp0RoH8jLPMfvXxskf6NvXHPaE0bokrIQKKddJFy4=.cac024c3-cc0d-4547-9d04-a63e85b0b86d@github.com>

On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fail early on Windows, and more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 87:

> 85:             = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
> 86:             .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
> 87:     private static final ValueLayout.OfLong C_SIZE_T

Note that portability between 32/64 is hard, even if using canonicalLayouts -- because size_t will likely be an IntLayout on arm32, while a LongLayout in 64 bits. If you never use this layout to access data (e.g. call `MemorySegment::get/set`) I'd suggest to avoid the cast, and leave it just as `ValueLayout`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661342378

From weijun at openjdk.org  Mon Jan  5 16:13:56 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:13:56 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
Message-ID: <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>

On Mon, 5 Jan 2026 11:42:08 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Or I can call this `_posix_getpwuid_r` function if `isAix()` is true. Is this enough?
>> 
>>      private static final MethodHandle getpwuid_r = LINKER
>> -            .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
>> +            .downcallHandle(SYMBOL_LOOKUP.findOrThrow(
>> +                            OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>>                      FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
>> -                            C_SIZE_T, C_POINTER));
>> +                            OperatingSystem.isAix() ? C_INT : C_SIZE_T,
>> +                            C_POINTER));
>
> Thank you for taking care of it! I appreciate it. This has worked:
> 
> diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> index ee2c5effcf0..3afab6f7974 100644
> --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> @@ -38,6 +38,8 @@
>  import java.lang.invoke.MethodHandle;
>  import java.lang.invoke.VarHandle;
>  
> +import jdk.internal.util.OperatingSystem;
> +
>  import static java.lang.foreign.MemoryLayout.PathElement.groupElement;
>  
>  /**
> @@ -106,9 +108,9 @@ public class UnixSystem {
>              .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getgid"),
>                      FunctionDescriptor.of(C_INT));
>      private static final MethodHandle getpwuid_r = LINKER
> -            .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
> +            .downcallHandle(SYMBOL_LOOKUP.findOrThrow(OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>                      FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
> -                            C_SIZE_T, C_POINTER));
> +                            OperatingSystem.isAix() ? C_INT : C_SIZE_T, C_POINTER));
>  
>      private static final GroupLayout passwd_layout = MemoryLayout.structLayout(
>              C_POINTER.withName("pw_name"),
> @@ -136,7 +138,7 @@ public class UnixSystem {
>      // sysconf(_SC_GETPW_R_SIZE_MAX) on macOS is 4096 and 1024 on Linux.
>      // Not calling sysconf() here because _SC_GETPW_R_SIZE_MAX is different
>      // on different platforms.
> -    private static final long GETPW_R_SIZE_MAX = 4096L;
> +    private static final int GETPW_R_SIZE_MAX = 4096;
>  
>      /**
>       * Instantiate a {@code UnixSystem} and load
> 
> Note that `GETPW_R_SIZE_MAX` needs to be an `int` because `long` to `int` conversion would require an explicit cast (probably also for arm32). The other way round works implicitly.
> 
> I'd like to have feedback from the AIX experts as well. They may still be on vacation for a couple of days.
> 
> We still have a potential problem with the UID parameter. We are using an `int`, but the C code expects an `uint32_t`. Some platforms pass 32 bit values in 64 bit registers and expect a proper extension (zero for unsigned and sign for signed). If the UID becomes larger than INT_MAX, we use sign extend which is wrong.
> Not sure of anyone uses so large UIDs and if we could re...

Maybe we can call `Integer.toUnsignedLong()` on `pw_uid` and `pw_gid`? In `UnixSystem`, they are `long`s.

Also, I want to discuss on the `username` issue again. Do you think it's good to login successfully without a `UnixPrincipal`? Now that there is a way on AIX to get it, I'm more inclined to revert the changes made to `UnixLoginModule`. While the old `Unix.c` seems to support username being `null` we know it would fail later with an NPE so this has never really worked before. My current understanding is that silent passing the login without a username might hide a bug and if the user takes it for granted that there should be a `UnixPrincipal` there will be a problem sooner or later. In fact, I would suggest we just throw an exception in `UnixSystem` if `getpwuid_r` cannot find the username.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662017228

From weijun at openjdk.org  Mon Jan  5 16:13:59 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:13:59 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <YmTo5WCxbz1LGGAcqF4uvO40BE_h140JJd4KgQKdiv0=.55098fd6-44c2-40cb-b7ea-04fa33d0c603@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <YmTo5WCxbz1LGGAcqF4uvO40BE_h140JJd4KgQKdiv0=.55098fd6-44c2-40cb-b7ea-04fa33d0c603@github.com>
Message-ID: <NKK-NfqezDDUZZV3FstBWr23mwI6Ghn7DBcaVoE5O9o=.9498da1e-71c8-48d0-b2d8-c4549efeef4a@github.com>

On Mon, 5 Jan 2026 12:25:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail early on Windows, and more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 90:
> 
>> 88:             = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("size_t");
>> 89: 
>> 90:     private static Linker.Option ccs = Linker.Option.captureCallState("errno");
> 
> names of static final fields should be capitalized?

I inlined it instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662029528

From weijun at openjdk.org  Mon Jan  5 16:19:17 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:19:17 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <PFJp0RoH8jLPMfvXxskf6NvXHPaE0bokrIQKKddJFy4=.cac024c3-cc0d-4547-9d04-a63e85b0b86d@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <PFJp0RoH8jLPMfvXxskf6NvXHPaE0bokrIQKKddJFy4=.cac024c3-cc0d-4547-9d04-a63e85b0b86d@github.com>
Message-ID: <SAijOJraT5hbaHXrIXVSlRqGyPqusiC9iKZ-LEkzRlI=.a8290ae1-a9d2-41c5-9ccb-6e006dcc777d@github.com>

On Mon, 5 Jan 2026 12:31:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail early on Windows, and more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 87:
> 
>> 85:             = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
>> 86:             .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
>> 87:     private static final ValueLayout.OfLong C_SIZE_T
> 
> Note that portability between 32/64 is hard, even if using canonicalLayouts -- because size_t will likely be an IntLayout on arm32, while a LongLayout in 64 bits. If you never use this layout to access data (e.g. call `MemorySegment::get/set`) I'd suggest to avoid the cast, and leave it just as `ValueLayout`

Ah yes, thanks for pointing out. I forgot to update it when changing "long" to "size_t".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662046816

From weijun at openjdk.org  Mon Jan  5 16:30:23 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:30:23 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v6]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <Zufe94LY_ro6POHQNEfN8MvXOD6TgWzAd7QZ9X4E99U=.3902059a-af7f-42bc-995b-7e5aba8ba82d@github.com>

> Rewrite the native calls with FFM.

Weijun Wang 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 eight additional commits since the last revision:

 - address comments from Maurizio; support AIX-specific `_posix_getpwuid_r`; recover unsigned int
 - Merge branch 'master' into 8277489
 - fail early on Windows, and more comments
 - use size_t
 - error handling
 - rewrite without jextract
 - no tabs
 - the fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/578f1d2e..b54ca67c

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

  Stats: 5209 lines in 1977 files changed: 1372 ins; 600 del; 3237 mod
  Patch: https://git.openjdk.org/jdk/pull/28931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931

PR: https://git.openjdk.org/jdk/pull/28931

From mdoerr at openjdk.org  Mon Jan  5 16:39:43 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Jan 2026 16:39:43 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
Message-ID: <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>

On Mon, 5 Jan 2026 16:06:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs.

Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`.
However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended.

> I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username.

Fine with me. I don't like ignoring getpwuid_r failures, either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662113718

From weijun at openjdk.org  Mon Jan  5 16:49:05 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:49:05 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
Message-ID: <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>

On Mon, 5 Jan 2026 16:36:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Maybe we can call `Integer.toUnsignedLong()` on `pw_uid` and `pw_gid`? In `UnixSystem`, they are `long`s.
>> 
>> Also, I want to discuss on the `username` issue again. Do you think it's good to login successfully without a `UnixPrincipal`? Now that there is a way on AIX to get it, I'm more inclined to revert the changes made to `UnixLoginModule`. While the old `Unix.c` seems to support username being `null` we know it would fail immediately with an NPE so this has never really worked before. My current understanding is that silent passing the login without a username might hide a bug and if the user takes it for granted that there should be a `UnixPrincipal` there will be a problem sooner or later. In fact, I would suggest we just throw an exception in `UnixSystem` if `getpwuid_r` cannot find the username.
>
>> Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs.
> 
> Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`.
> However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
> In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended.
> 
>> I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username.
> 
> Fine with me. I don't like ignoring getpwuid_r failures, either.

I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`.  The results always look good after a `Integer.toUnsignedLong()` conversion.

I would think it's safe because it's only called after the C functions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662146915

From weijun at openjdk.org  Mon Jan  5 17:20:29 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 17:20:29 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>

> Rewrite the native calls with FFM.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  must have username; more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/b54ca67c..cfd794b8

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

  Stats: 43 lines in 2 files changed: 5 ins; 25 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931

PR: https://git.openjdk.org/jdk/pull/28931

From mdoerr at openjdk.org  Mon Jan  5 18:02:11 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Jan 2026 18:02:11 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
Message-ID: <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkNGApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>

On Mon, 5 Jan 2026 16:46:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs.
>> 
>> Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`.
>> However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
>> In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended.
>> 
>>> I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username.
>> 
>> Fine with me. I don't like ignoring getpwuid_r failures, either.
>
> I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`.  The results always look good after a `Integer.toUnsignedLong()` conversion.
> 
> I would think it's safe because it's only called after the C functions.

What you have done is fine. Thanks! However, there is one potential problem left:
We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX):

[2.537s][trace][foreign,downcall]  ;; { argument shuffle
[2.537s][trace][foreign,downcall]   0x0a0001000747d744:   mr      r12,r3
[2.537s][trace][foreign,downcall]   0x0a0001000747d748:   extsw   r3,r4
[2.537s][trace][foreign,downcall]   0x0a0001000747d74c:   mr      r4,r5
[2.537s][trace][foreign,downcall]   0x0a0001000747d750:   mr      r5,r6
[2.537s][trace][foreign,downcall]   0x0a0001000747d754:   extsw   r6,r7
[2.537s][trace][foreign,downcall]   0x0a0001000747d758:   mr      r7,r8
[2.537s][trace][foreign,downcall]  ;; } argument shuffle

The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend.

A possible workaround would be to do the conversion in Java and passing it as long:

diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
index ed520529ac8..573513b7bef 100644
--- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
+++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
@@ -25,6 +25,7 @@
 
 package com.sun.security.auth.module;
 
+import jdk.internal.util.Architecture;
 import jdk.internal.util.OperatingSystem;
 
 import java.lang.foreign.AddressLayout;
@@ -83,6 +84,8 @@ public class UnixSystem {
             = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char");
     private static final ValueLayout.OfInt C_INT
             = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int");
+    private static final ValueLayout.OfLong C_LONG
+            = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
     private static final AddressLayout C_POINTER
             = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
             .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
@@ -110,10 +113,14 @@ public class UnixSystem {
 
     // getpwuid_r does not work on AIX, instead we use another similar function
     // extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)
+    // At least the following architecture require appropriate zero or sign extension to 64 bit.
+    private static final boolean calling_convention_requires_int_as_long = Architecture.isPPC64() || Architecture.isPPC64LE() || Architecture.isS390();
     private static final MethodHandle getpwuid_r = LINKER
             .downcallHandle(SYMBOL_LOOKUP.findOrThrow(
                             OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
-                    FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
+                    FunctionDescriptor.of(C_INT,
+                            calling_convention_requires_int_as_long ? C_LONG : C_INT,
+                            C_POINTER, C_POINTER,
                             OperatingSystem.isAix() ? C_INT : C_SIZE_T,
                             C_POINTER));
 
@@ -179,11 +186,15 @@ public UnixSystem() {
             var pwd = scope.allocate(passwd_layout);
             var result = scope.allocate(C_POINTER);
             var buffer = scope.allocate(GETPW_R_SIZE_MAX);
-            var tmpUid = (int)getuid.invokeExact();
+            long tmpUid = Integer.toUnsignedLong((int) getuid.invokeExact());
             // Do not call invokeExact because the type of buffer_size is not
             // always long in the underlying system.
-            int out = (int) getpwuid_r.invoke(
-                    tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result);
+            int out = 0;
+            if (calling_convention_requires_int_as_long) {
+                out = (int) getpwuid_r.invoke(tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result);
+            } else {
+                out = (int) getpwuid_r.invoke((int) tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result);
+            }
             if (out != 0 || result.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)) {
                 if (out != 0) {
                     // If ERANGE (Result too large) is detected in a new platform,
@@ -193,7 +204,7 @@ public UnixSystem() {
                 } else {
                     getpwuid_r_error = "the requested entry is not found";
                 }
-                uid = Integer.toUnsignedLong(tmpUid);
+                uid = tmpUid;
                 gid = Integer.toUnsignedLong((int)getgid.invokeExact());
                 username = null;
             } else {

But I don't really like it. I hope we can find a better solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662361633

From dmlloyd at openjdk.org  Mon Jan  5 18:14:55 2026
From: dmlloyd at openjdk.org (David Lloyd)
Date: Mon, 5 Jan 2026 18:14:55 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkNGApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
Message-ID: <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>

On Mon, 5 Jan 2026 18:00:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`.  The results always look good after a `Integer.toUnsignedLong()` conversion.
>> 
>> I would think it's safe because it's only called after the C functions.
>
> What you have done is fine. Thanks! However, there is one potential problem left:
> We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX):
> 
> [2.537s][trace][foreign,downcall]  ;; { argument shuffle
> [2.537s][trace][foreign,downcall]   0x0a0001000747d744:   mr      r12,r3
> [2.537s][trace][foreign,downcall]   0x0a0001000747d748:   extsw   r3,r4
> [2.537s][trace][foreign,downcall]   0x0a0001000747d74c:   mr      r4,r5
> [2.537s][trace][foreign,downcall]   0x0a0001000747d750:   mr      r5,r6
> [2.537s][trace][foreign,downcall]   0x0a0001000747d754:   extsw   r6,r7
> [2.537s][trace][foreign,downcall]   0x0a0001000747d758:   mr      r7,r8
> [2.537s][trace][foreign,downcall]  ;; } argument shuffle
> 
> The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend.
> 
> A possible workaround would be to do the conversion in Java and passing it as long:
> 
> diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> index ed520529ac8..573513b7bef 100644
> --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> @@ -25,6 +25,7 @@
>  
>  package com.sun.security.auth.module;
>  
> +import jdk.internal.util.Architecture;
>  import jdk.internal.util.OperatingSystem;
>  
>  import java.lang.foreign.AddressLayout;
> @@ -83,6 +84,8 @@ public class UnixSystem {
>              = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char");
>      private static final ValueLayout.OfInt C_INT
>              = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int");
> +    private static final ValueLayout.OfLong C_LONG
> +            = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
>      private static final AddressLayout C_POINTER
>              = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
>              .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
> @@ -110,10 +113,14 @@ public class UnixSystem {
>  
>      // getpwuid_r does not work on AIX, instead we use another similar function
>      // extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)
> +  ...

FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662391104

From shade at openjdk.org  Mon Jan  5 18:21:23 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Jan 2026 18:21:23 GMT
Subject: RFR: 8374507: GHA: Limit debug symbols generation to conserve disk
 space
Message-ID: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>

I have noticed that Linux x86_64 fastdebug build jobs started to fail in GHA with no free space left on device. Instrumenting GHA runs shows we have about 17G of free space on those runners. 


Filesystem  Size  Used  Avail Use% Mounted on
/dev/root    72G   56G   17G   78% /


[GHA docs](https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) say there is 14G of guaranteed disk space on runners. This is a bit beyond what our fastdebug builds need. My local build says disabling debug symbols bundling reduces the space requirement from 16G -> 11G, without regressing tests.

Testing:
 - [x] Ad-hoc JVM crash to verify that stack trace generation still works
 - [ ] GHA

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

Commit messages:
 - Try external-symbols-in-bundles=none
 - Handle the absence of symbols gracefully
 - Fix

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

PR: https://git.openjdk.org/jdk/pull/29030

From erikj at openjdk.org  Mon Jan  5 18:40:04 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 Jan 2026 18:40:04 GMT
Subject: RFR: 8374507: GHA: Limit debug symbols generation to conserve disk
 space
In-Reply-To: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
References: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
Message-ID: <kn3y8RKB5otgiy-7U0SZIRT_iIarnWvt8QtinTrej5I=.2cf1ddfa-9abe-4ca1-8951-9fe246871108@github.com>

On Mon, 5 Jan 2026 08:54:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that Linux x86_64 fastdebug build jobs started to fail in GHA with no free space left on device. Instrumenting GHA runs shows we have about 17G of free space on those runners. 
> 
> 
> Filesystem  Size  Used  Avail Use% Mounted on
> /dev/root    72G   56G   17G   78% /
> 
> 
> [GHA docs](https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) say there is 14G of guaranteed disk space on runners. This is a bit beyond what our fastdebug builds need. My local build says disabling debug symbols bundling reduces the space requirement from 16G -> 11G, without regressing tests.
> 
> Testing:
>  - [x] Ad-hoc JVM crash to verify that stack trace generation still works
>  - [ ] GHA

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29030#pullrequestreview-3628009362

From amenkov at openjdk.org  Mon Jan  5 20:01:18 2026
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 5 Jan 2026 20:01:18 GMT
Subject: Integrated: 8374168: Resolve disabled warnings in JDWP agent
In-Reply-To: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
References: <-JtoYbutzvGGk3oznveEyfkic5KNdtWNHzXozHvVcHQ=.dd0b6563-d512-4a14-864d-91c776010aa7@github.com>
Message-ID: <gw2gtAhas3Woau2rBJIBFjawQ5_-GOVGvMs2hbpXay4=.511cd1f1-5fd7-44e7-a291-1c2cf4b59c3d@github.com>

On Sat, 20 Dec 2025 02:08:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix resolves disabled warnings in debugger agent

This pull request has now been integrated.

Changeset: fa8ea6b3
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa8ea6b32d463a84affa529d37cfb97280503fc6
Stats:     65 lines in 11 files changed: 19 ins; 33 del; 13 mod

8374168: Resolve disabled warnings in JDWP agent

Reviewed-by: cjplummer, sspitsyn, erikj

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

PR: https://git.openjdk.org/jdk/pull/28937

From bpb at openjdk.org  Mon Jan  5 20:49:23 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Jan 2026 20:49:23 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v19]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <kFhaxXu-xFdJ8f7vJ03SBs-AGWtje9R4exhzQlbED3U=.ff0ecdd9-8284-452f-a6a8-7102cc61fb62@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 9 more: https://git.openjdk.org/jdk/compare/27dbdec2...c7446357

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=18
  Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From weijun at openjdk.org  Mon Jan  5 21:34:16 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 21:34:16 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
Message-ID: <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>

On Mon, 5 Jan 2026 18:12:08 GMT, David Lloyd <dmlloyd at openjdk.org> wrote:

>> What you have done is fine. Thanks! However, there is one potential problem left:
>> We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX):
>> 
>> [2.537s][trace][foreign,downcall]  ;; { argument shuffle
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d744:   mr      r12,r3
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d748:   extsw   r3,r4
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d74c:   mr      r4,r5
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d750:   mr      r5,r6
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d754:   extsw   r6,r7
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d758:   mr      r7,r8
>> [2.537s][trace][foreign,downcall]  ;; } argument shuffle
>> 
>> The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend.
>> 
>> A possible workaround would be to do the conversion in Java and passing it as long:
>> 
>> diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
>> index ed520529ac8..573513b7bef 100644
>> --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
>> +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
>> @@ -25,6 +25,7 @@
>>  
>>  package com.sun.security.auth.module;
>>  
>> +import jdk.internal.util.Architecture;
>>  import jdk.internal.util.OperatingSystem;
>>  
>>  import java.lang.foreign.AddressLayout;
>> @@ -83,6 +84,8 @@ public class UnixSystem {
>>              = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char");
>>      private static final ValueLayout.OfInt C_INT
>>              = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int");
>> +    private static final ValueLayout.OfLong C_LONG
>> +            = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
>>      private static final AddressLayout C_POINTER
>>              = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
>>              .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
>> @@ -110,10 +113,14 @@ public class UnixSystem {
>>  
>>      // getpwuid_r does not work on AIX, instead we use another similar function
>>      // exter...
>
> FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664

\What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662861217

From shade at openjdk.org  Tue Jan  6 07:43:32 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 07:43:32 GMT
Subject: RFR: 8374507: GHA: Limit debug symbols generation to conserve disk
 space
In-Reply-To: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
References: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
Message-ID: <mzOLXLI6jOPCItbHJzoYAnzVdO9RxIk_kfRGsqGSBdg=.52fef439-048d-48e9-84ae-31fa1b938b95@github.com>

On Mon, 5 Jan 2026 08:54:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that Linux x86_64 fastdebug build jobs started to fail in GHA with no free space left on device. Instrumenting GHA runs shows we have about 17G of free space on those runners. 
> 
> 
> Filesystem  Size  Used  Avail Use% Mounted on
> /dev/root    72G   56G   17G   78% /
> 
> 
> [GHA docs](https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) say there is 14G of guaranteed disk space on runners. This is a bit beyond what our fastdebug builds need. My local build says disabling debug symbols bundling reduces the space requirement from 16G -> 11G, without regressing tests.
> 
> Testing:
>  - [x] Ad-hoc JVM crash to verify that stack trace generation still works
>  - [x] GHA

Thank you! I am integrating now to unbreak GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/29030#issuecomment-3713526817

From shade at openjdk.org  Tue Jan  6 07:43:32 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 07:43:32 GMT
Subject: Integrated: 8374507: GHA: Limit debug symbols generation to conserve
 disk space
In-Reply-To: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
References: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
Message-ID: <UfMEE36nU9r4p4PzHLtzVAyUz3qnsL-Wm-nDGilJzqg=.7f1c723c-e9ce-48a9-82b5-510fb10c93b7@github.com>

On Mon, 5 Jan 2026 08:54:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that Linux x86_64 fastdebug build jobs started to fail in GHA with no free space left on device. Instrumenting GHA runs shows we have about 17G of free space on those runners. 
> 
> 
> Filesystem  Size  Used  Avail Use% Mounted on
> /dev/root    72G   56G   17G   78% /
> 
> 
> [GHA docs](https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) say there is 14G of guaranteed disk space on runners. This is a bit beyond what our fastdebug builds need. My local build says disabling debug symbols bundling reduces the space requirement from 16G -> 11G, without regressing tests.
> 
> Testing:
>  - [x] Ad-hoc JVM crash to verify that stack trace generation still works
>  - [x] GHA

This pull request has now been integrated.

Changeset: d063c954
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d063c9546b4a500f4c76fcd01442c2b7281f6d65
Stats:     5 lines in 5 files changed: 5 ins; 0 del; 0 mod

8374507: GHA: Limit debug symbols generation to conserve disk space

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk/pull/29030

From clanger at openjdk.org  Tue Jan  6 08:48:22 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 6 Jan 2026 08:48:22 GMT
Subject: RFR: 8374507: GHA: Limit debug symbols generation to conserve disk
 space
In-Reply-To: <mzOLXLI6jOPCItbHJzoYAnzVdO9RxIk_kfRGsqGSBdg=.52fef439-048d-48e9-84ae-31fa1b938b95@github.com>
References: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
 <mzOLXLI6jOPCItbHJzoYAnzVdO9RxIk_kfRGsqGSBdg=.52fef439-048d-48e9-84ae-31fa1b938b95@github.com>
Message-ID: <HKc-cMowaK9UrpVlpMOD4oS0gGBE7KMz2SnoC6t5JB8=.6109c828-aeb2-4510-8467-a2b73d2aec76@github.com>

On Tue, 6 Jan 2026 07:38:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have noticed that Linux x86_64 fastdebug build jobs started to fail in GHA with no free space left on device. Instrumenting GHA runs shows we have about 17G of free space on those runners. 
>> 
>> 
>> Filesystem  Size  Used  Avail Use% Mounted on
>> /dev/root    72G   56G   17G   78% /
>> 
>> 
>> [GHA docs](https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) say there is 14G of guaranteed disk space on runners. This is a bit beyond what our fastdebug builds need. My local build says disabling debug symbols bundling reduces the space requirement from 16G -> 11G, without regressing tests.
>> 
>> Testing:
>>  - [x] Ad-hoc JVM crash to verify that stack trace generation still works
>>  - [x] GHA
>
> Thank you! I am integrating now to unbreak GHA.

@shipilev I'm a bit late to the game here but maybe we should try --with-external-symbols-in-bundles=public on Windows in order to get file and method names in case of crashes. Not sure whether it'll be again too much of disk space needed, though...

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

PR Comment: https://git.openjdk.org/jdk/pull/29030#issuecomment-3713728295

From shade at openjdk.org  Tue Jan  6 08:59:17 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 08:59:17 GMT
Subject: RFR: 8374507: GHA: Limit debug symbols generation to conserve disk
 space
In-Reply-To: <mzOLXLI6jOPCItbHJzoYAnzVdO9RxIk_kfRGsqGSBdg=.52fef439-048d-48e9-84ae-31fa1b938b95@github.com>
References: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
 <mzOLXLI6jOPCItbHJzoYAnzVdO9RxIk_kfRGsqGSBdg=.52fef439-048d-48e9-84ae-31fa1b938b95@github.com>
Message-ID: <6Ywe1f8vgxXHvbERfo9Oj4mFKxvs97q5_QvJSfOLWhc=.8aca2f92-9895-44f4-b9bb-bf81b74c7f57@github.com>

On Tue, 6 Jan 2026 07:38:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have noticed that Linux x86_64 fastdebug build jobs started to fail in GHA with no free space left on device. Instrumenting GHA runs shows we have about 17G of free space on those runners. 
>> 
>> 
>> Filesystem  Size  Used  Avail Use% Mounted on
>> /dev/root    72G   56G   17G   78% /
>> 
>> 
>> [GHA docs](https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) say there is 14G of guaranteed disk space on runners. This is a bit beyond what our fastdebug builds need. My local build says disabling debug symbols bundling reduces the space requirement from 16G -> 11G, without regressing tests.
>> 
>> Testing:
>>  - [x] Ad-hoc JVM crash to verify that stack trace generation still works
>>  - [x] GHA
>
> Thank you! I am integrating now to unbreak GHA.

> @shipilev I'm a bit late to the game here but maybe we should try --with-external-symbols-in-bundles=public on Windows in order to get file and method names in case of crashes. Not sure whether it'll be again too much of disk space needed, though...

Oh. Yes, please try that? Really we wanted to improve Linux side of things, that is where we are scratching the runner space limits. I have not looked at Windows side at all; so please experiment and see how bad is it? I also have this improvement for Linux/MacOS: https://github.com/openjdk/jdk/pull/29056 -- again, does not help Windows, since I cannot find a useful/relevant MSVC toggle there.

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

PR Comment: https://git.openjdk.org/jdk/pull/29030#issuecomment-3713766995

From shade at openjdk.org  Tue Jan  6 13:21:20 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 13:21:20 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels
Message-ID: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>

[JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html

Allowing users to configure the debug level allows two major deviations from the default level (2):
 level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
 level=3: add even more debugging info, like macro expansion, into the debug data

This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.

I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 

I am open for bikeshedding on the option name :)

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

Commit messages:
 - Fallback when compiler does not support the value
 - Also enable in GHA
 - Debug levels

Changes: https://git.openjdk.org/jdk/pull/29056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374521
  Stats: 25 lines in 5 files changed: 21 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29056/head:pull/29056

PR: https://git.openjdk.org/jdk/pull/29056

From shade at openjdk.org  Tue Jan  6 13:21:21 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 13:21:21 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels
In-Reply-To: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
Message-ID: <ATcTcOL0NfZEXADo9uheuml14Cbz0AH89TmXITyke7E=.01feafab-1ddb-4b16-8d8a-6cce048ade55@github.com>

On Tue, 6 Jan 2026 08:28:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
> 
> Allowing users to configure the debug level allows two major deviations from the default level (2):
>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>  level=3: add even more debugging info, like macro expansion, into the debug data
> 
> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
> 
> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
> 
> I am open for bikeshedding on the option name :)

Motivational improvements in debug info sizes:


$ ls -sh ./build/linux-x86_64-server-fastdebug/images/jdk/lib/server/libjvm.debuginfo
# level=1: 144M
# level=2: 860M
# level=3: 892M


Since debuginfo-s are duplicated several times in our build dir, we are scratching against the 14G guaranteed free space on GHA runners, and reducing to level=1 buys us a lot of headroom:


$ du -sh build/linux-x86_64-server-fastdebug/
# level=1:  4.0G
# level=2: 14.0G
# level=3: 16.0G

Similar thing on MacOS AArch64 (Clang):


% du -sh ./build/macosx-aarch64-server-fastdebug/images/jdk/lib/server/libjvm.dylib.dSYM/ 
# level=1:  92M
# level=2: 202M
# level=3: 202M

% du -sh ./build/macosx-aarch64-server-fastdebug/     
# level=1: 3.6G
# level=2: 5.6G
# level=3: 5.6G

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3713722791
PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3714487776

From krk at openjdk.org  Tue Jan  6 14:03:07 2026
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 6 Jan 2026 14:03:07 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels
In-Reply-To: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
Message-ID: <7r2x8uLyWx8wc6euesl7W4Qu4KMPg26N08G7trp4vTc=.3dae9796-a946-4a09-b3c8-96c231683921@github.com>

On Tue, 6 Jan 2026 08:28:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
> 
> Allowing users to configure the debug level allows two major deviations from the default level (2):
>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>  level=3: add even more debugging info, like macro expansion, into the debug data
> 
> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
> 
> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
> 
> I am open for bikeshedding on the option name :)

make/autoconf/flags-cflags.m4 line 72:

> 70:   DEBUG_PREFIX_CFLAGS=
> 71: 
> 72:   UTIL_ARG_WITH(NAME: fine-debug-level, TYPE: string,

How about `debug-info-level`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29056#discussion_r2665018759

From erikj at openjdk.org  Tue Jan  6 14:20:20 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Jan 2026 14:20:20 GMT
Subject: RFR: 8374507: GHA: Limit debug symbols generation to conserve disk
 space
In-Reply-To: <6Ywe1f8vgxXHvbERfo9Oj4mFKxvs97q5_QvJSfOLWhc=.8aca2f92-9895-44f4-b9bb-bf81b74c7f57@github.com>
References: <eNRkZA-H6-GV2NjQXGMAiDGTCet3sAwyGIuYt_GZDNo=.3a17b242-5738-4e31-a099-b2e2f173ffd2@github.com>
 <mzOLXLI6jOPCItbHJzoYAnzVdO9RxIk_kfRGsqGSBdg=.52fef439-048d-48e9-84ae-31fa1b938b95@github.com>
 <6Ywe1f8vgxXHvbERfo9Oj4mFKxvs97q5_QvJSfOLWhc=.8aca2f92-9895-44f4-b9bb-bf81b74c7f57@github.com>
Message-ID: <D25RRc6SVr-EmSVQwT3CKx_-UuzFe2CoCg9alqijJbI=.22b67c83-ad85-4e27-866c-ce72126c8414@github.com>

On Tue, 6 Jan 2026 08:55:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I'm a bit late to the game here but maybe we should try --with-external-symbols-in-bundles=public on Windows in order to get file and method names in case of crashes. Not sure whether it'll be again too much of disk space needed, though...

RunTests.gmk sets up `_NT_SYMBOL_PATH` based on `$(SYMBOLS_IMAGE_DIR)` if that is provided when invoking `make run-test-prebuilt`. At least in our internal testing setup, we get symbols for Windows crashes. Is that not the case in GHA?

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

PR Comment: https://git.openjdk.org/jdk/pull/29030#issuecomment-3714863188

From erikj at openjdk.org  Tue Jan  6 14:23:17 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Jan 2026 14:23:17 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels
In-Reply-To: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
Message-ID: <_fE7-ImucRtgRVFCRnSu3Fx_eTKFicwxksGkGrign24=.b333a828-4f8d-4110-b8c6-29d4f2fd402a@github.com>

On Tue, 6 Jan 2026 08:28:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
> 
> Allowing users to configure the debug level allows two major deviations from the default level (2):
>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>  level=3: add even more debugging info, like macro expansion, into the debug data
> 
> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
> 
> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
> 
> I am open for bikeshedding on the option name :)

I think this is a good idea.

make/autoconf/flags-cflags.m4 line 75:

> 73:     DEFAULT: 2,
> 74:     RESULT: FINE_DEBUG_LEVEL,
> 75:     DESC: [Sets the fine-tuned debug level, when debug info generation is enabled],

I think we should clarify that this only applies to GCC and Clang.

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

PR Review: https://git.openjdk.org/jdk/pull/29056#pullrequestreview-3631080013
PR Review Comment: https://git.openjdk.org/jdk/pull/29056#discussion_r2665086250

From erikj at openjdk.org  Tue Jan  6 14:23:20 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Jan 2026 14:23:20 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels
In-Reply-To: <7r2x8uLyWx8wc6euesl7W4Qu4KMPg26N08G7trp4vTc=.3dae9796-a946-4a09-b3c8-96c231683921@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <7r2x8uLyWx8wc6euesl7W4Qu4KMPg26N08G7trp4vTc=.3dae9796-a946-4a09-b3c8-96c231683921@github.com>
Message-ID: <FJW-FdQCtuFb-mErL0oBK5-7fe0QdRmRW3LI6JXn4zs=.74b33b0d-4ef6-4f02-a574-94c2be01583e@github.com>

On Tue, 6 Jan 2026 13:58:57 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> make/autoconf/flags-cflags.m4 line 72:
> 
>> 70:   DEBUG_PREFIX_CFLAGS=
>> 71: 
>> 72:   UTIL_ARG_WITH(NAME: fine-debug-level, TYPE: string,
> 
> How about `debug-info-level`?

I think I agree with this naming suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29056#discussion_r2665084455

From shade at openjdk.org  Tue Jan  6 15:47:31 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 15:47:31 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v2]
In-Reply-To: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
Message-ID: <Aer_6Ire0c7RDb_IgESb9m9sN3GgQ21zBOjRtuPPytc=.dfdc532d-03fa-4413-8bbc-f5f284a1dfec@github.com>

> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
> 
> Allowing users to configure the debug level allows two major deviations from the default level (2):
>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>  level=3: add even more debugging info, like macro expansion, into the debug data
> 
> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
> 
> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
> 
> I am open for bikeshedding on the option name :)

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  --with-debug-info-level

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29056/files
  - new: https://git.openjdk.org/jdk/pull/29056/files/ebca865c..4971365c

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

  Stats: 21 lines in 5 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/29056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29056/head:pull/29056

PR: https://git.openjdk.org/jdk/pull/29056

From shade at openjdk.org  Tue Jan  6 15:47:34 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 15:47:34 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v2]
In-Reply-To: <FJW-FdQCtuFb-mErL0oBK5-7fe0QdRmRW3LI6JXn4zs=.74b33b0d-4ef6-4f02-a574-94c2be01583e@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <7r2x8uLyWx8wc6euesl7W4Qu4KMPg26N08G7trp4vTc=.3dae9796-a946-4a09-b3c8-96c231683921@github.com>
 <FJW-FdQCtuFb-mErL0oBK5-7fe0QdRmRW3LI6JXn4zs=.74b33b0d-4ef6-4f02-a574-94c2be01583e@github.com>
Message-ID: <nk4zJ8FM7ERFQkOaSLsAFkG_zEf8mZNcD-DzHg8DzRI=.87a4884e-166e-45e9-8d5c-41224d9d4e4a@github.com>

On Tue, 6 Jan 2026 14:20:14 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 72:
>> 
>>> 70:   DEBUG_PREFIX_CFLAGS=
>>> 71: 
>>> 72:   UTIL_ARG_WITH(NAME: fine-debug-level, TYPE: string,
>> 
>> How about `debug-info-level`?
>
> I think I agree with this naming suggestion.

`--with-debug-info-level` it is!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29056#discussion_r2665352859

From shade at openjdk.org  Tue Jan  6 15:47:37 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 15:47:37 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v2]
In-Reply-To: <_fE7-ImucRtgRVFCRnSu3Fx_eTKFicwxksGkGrign24=.b333a828-4f8d-4110-b8c6-29d4f2fd402a@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <_fE7-ImucRtgRVFCRnSu3Fx_eTKFicwxksGkGrign24=.b333a828-4f8d-4110-b8c6-29d4f2fd402a@github.com>
Message-ID: <riNFM-Eig81RZ1Fg5Z2UVV6SmXCeM0jS_c2pqC9KySE=.462b8e6b-12bd-460f-bb96-8529105f8276@github.com>

On Tue, 6 Jan 2026 14:20:43 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   --with-debug-info-level
>
> make/autoconf/flags-cflags.m4 line 75:
> 
>> 73:     DEFAULT: 2,
>> 74:     RESULT: FINE_DEBUG_LEVEL,
>> 75:     DESC: [Sets the fine-tuned debug level, when debug info generation is enabled],
> 
> I think we should clarify that this only applies to GCC and Clang.

I added the blurb into description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29056#discussion_r2665353325

From shade at openjdk.org  Tue Jan  6 16:02:51 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 16:02:51 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
Message-ID: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>

> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
> 
> Allowing users to configure the debug level allows two major deviations from the default level (2):
>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>  level=3: add even more debugging info, like macro expansion, into the debug data
> 
> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
> 
> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
> 
> I am open for bikeshedding on the option name :)

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Default to default, common the block, fail on incorrect debug level

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29056/files
  - new: https://git.openjdk.org/jdk/pull/29056/files/4971365c..6365bb9d

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

  Stats: 19 lines in 1 file changed: 10 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29056/head:pull/29056

PR: https://git.openjdk.org/jdk/pull/29056

From shade at openjdk.org  Tue Jan  6 16:02:53 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Jan 2026 16:02:53 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v2]
In-Reply-To: <Aer_6Ire0c7RDb_IgESb9m9sN3GgQ21zBOjRtuPPytc=.dfdc532d-03fa-4413-8bbc-f5f284a1dfec@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <Aer_6Ire0c7RDb_IgESb9m9sN3GgQ21zBOjRtuPPytc=.dfdc532d-03fa-4413-8bbc-f5f284a1dfec@github.com>
Message-ID: <FvKQiDbXRPm0PDVYm9iEUrhN-uerBNModXeQavk_-QA=.7b693013-6d9c-43fd-b249-41825fda2900@github.com>

On Tue, 6 Jan 2026 15:47:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   --with-debug-info-level

A few more touchups: moved the block to handle both compilers at the same time, stopped issuing `-g2` when default `-g` would do, started to fail when compiler rejects the debug info level requested.

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3715250904

From erikj at openjdk.org  Tue Jan  6 17:07:21 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Jan 2026 17:07:21 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <KlczBpIijX_SvfUhmI2p-Tw-fxN9my45EJ2k-08PLMc=.5b66ab7b-6598-45e1-8182-a259b3f6564a@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29056#pullrequestreview-3631719462

From krk at openjdk.org  Tue Jan  6 17:11:58 2026
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 6 Jan 2026 17:11:58 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <CW0Ga48TjlPRDkq-E9KVA5ptmksc4th4nc3xeX-7EfE=.61ecfe6b-5081-4acf-85a8-c42bc942313d@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

Marked as reviewed by krk (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/29056#pullrequestreview-3631743222

From haosun at openjdk.org  Wed Jan  7 00:49:00 2026
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 7 Jan 2026 00:49:00 GMT
Subject: [jdk26] RFR: 8373122: JFR build failure with CDS disabled due to
 -Werror=unused-function after JDK-8365400
In-Reply-To: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
References: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
Message-ID: <q3afwrU-1m_aBFZ8wxiypDHaswFXQdplOcOQVaou1R8=.95619c8c-4693-4e81-831f-876e162f818b@github.com>

On Wed, 24 Dec 2025 03:46:49 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e1d81c09](https://github.com/openjdk/jdk/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hao Sun on 23 Dec 2025 and was reviewed by Markus Gr?nlund, Jie Fu and Francesco Andreuzzi.
> 
> Thanks!

I would appreciate it if someone could help review this backport patch. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/28976#issuecomment-3716887426

From jiefu at openjdk.org  Wed Jan  7 00:55:02 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 7 Jan 2026 00:55:02 GMT
Subject: [jdk26] RFR: 8373122: JFR build failure with CDS disabled due to
 -Werror=unused-function after JDK-8365400
In-Reply-To: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
References: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
Message-ID: <WN2roRFKWtgM8TJzIuAKQPGLudR9slnB0QDEafTiiX8=.56909f8e-6006-4011-9b10-dc77f37db523@github.com>

On Wed, 24 Dec 2025 03:46:49 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e1d81c09](https://github.com/openjdk/jdk/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hao Sun on 23 Dec 2025 and was reviewed by Markus Gr?nlund, Jie Fu and Francesco Andreuzzi.
> 
> Thanks!

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28976#pullrequestreview-3632992405

From haosun at openjdk.org  Wed Jan  7 01:08:48 2026
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 7 Jan 2026 01:08:48 GMT
Subject: [jdk26] RFR: 8373122: JFR build failure with CDS disabled due to
 -Werror=unused-function after JDK-8365400
In-Reply-To: <PViA0hRxCtqlhllEWkHIVay6Ii2wM0LqT8tCrD4RRIU=.7999b121-ee3b-4e29-8583-a3510c770f4f@github.com>
References: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
 <PViA0hRxCtqlhllEWkHIVay6Ii2wM0LqT8tCrD4RRIU=.7999b121-ee3b-4e29-8583-a3510c770f4f@github.com>
Message-ID: <58efiiX1cRmDco5VZyabSIFcgxVYoA30NAUNkfqtmi8=.928a57dd-f690-4b90-85a2-a9e18e459767@github.com>

On Fri, 2 Jan 2026 11:40:12 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [e1d81c09](https://github.com/openjdk/jdk/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Hao Sun on 23 Dec 2025 and was reviewed by Markus Gr?nlund, Jie Fu and Francesco Andreuzzi.
>> 
>> Thanks!
>
> Marked as reviewed by fandreuzzi (Committer).

Thanks a lot for your reviews. @fandreuz @DamonFool

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

PR Comment: https://git.openjdk.org/jdk/pull/28976#issuecomment-3716921157

From haosun at openjdk.org  Wed Jan  7 01:08:50 2026
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 7 Jan 2026 01:08:50 GMT
Subject: [jdk26] Integrated: 8373122: JFR build failure with CDS disabled due
 to -Werror=unused-function after JDK-8365400
In-Reply-To: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
References: <bf8PYT6GJNX_OWCrzKFb-7rDf_iulAKltERahN_Mz0c=.9db96d5c-b011-455f-94c0-a85b89610af5@github.com>
Message-ID: <uQOpnTqbtZGjlT_O6TIJDwdREmDvU2GLnFlHMl65TGE=.d51c3818-2b53-483c-9a59-b423da33bbcb@github.com>

On Wed, 24 Dec 2025 03:46:49 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e1d81c09](https://github.com/openjdk/jdk/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hao Sun on 23 Dec 2025 and was reviewed by Markus Gr?nlund, Jie Fu and Francesco Andreuzzi.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3103fa08
Author:    Hao Sun <haosun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3103fa08bba95ec2c60458d1c5f128243e5ff5bc
Stats:     28 lines in 1 file changed: 14 ins; 14 del; 0 mod

8373122: JFR build failure with CDS disabled due to -Werror=unused-function after JDK-8365400

Reviewed-by: fandreuzzi, jiefu
Backport-of: e1d81c0946364a266a006481a8fbbac24c7e6c6a

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

PR: https://git.openjdk.org/jdk/pull/28976

From clanger at openjdk.org  Wed Jan  7 06:29:49 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 7 Jan 2026 06:29:49 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <TWiKf8rJWLkVitGgn60-UKlS64pMtw1prf7KeXbhHnU=.5d65f6cf-2d1b-4efd-b653-d0b59cd89547@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

Looks like a nice resource usage improvement

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29056#pullrequestreview-3633515288

From shade at openjdk.org  Wed Jan  7 06:59:36 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 06:59:36 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <EJi9oEYHMx2-ijbRgFt22PjMrAfJdgHlyKz1hY5kVWg=.ca9f9db8-eb91-4265-bd8a-7d7a76ce9ebc@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

Thanks for reviews! I am thinking to align the option name with current `--with-native-debug-symbols` better, since it is really about those. How about this?


  --with-native-debug-symbols-level
                          set the native debug symbols level (GCC and Clang only) [toolchain default]
  --with-native-debug-symbols
                          set the native debug symbol configuration (none,
                          internal, external, zipped) [varying]

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3717573901

From clanger at openjdk.org  Wed Jan  7 08:01:30 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 7 Jan 2026 08:01:30 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <JfFoXVxigr6SqgcXVCDeBZoWd20xNEOEeyLfFkWEXnc=.f679c4c8-97d7-4e40-b7bd-40ae553e5a3b@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

OK, yes, that sounds like a good suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3717721246

From pminborg at openjdk.org  Wed Jan  7 08:42:52 2026
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 Jan 2026 08:42:52 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <PXM7cvaq12FcA0_MMfWC363-ZEwGIcsKPYAmJldbpAo=.ba23d30e-4941-44ef-b462-df9a233c789f@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <hvzPGrqI0zAz8wtLd40PWgnkeSMGLFGO9moE8PLqLbM=.f605a45f-685c-4f2d-a9c4-073f0b81947d@github.com>
 <IluLLCRKvj27XmeyeHp_7jb6j0nf8mcew0AwBMhLHS4=.e836e787-c6e9-43a0-a2d5-26f93bd67e28@github.com>
 <PXM7cvaq12FcA0_MMfWC363-ZEwGIcsKPYAmJldbpAo=.ba23d30e-4941-44ef-b462-df9a233c789f@github.com>
Message-ID: <R02gC6zZP9ySKeewnlGsQ_Aa48K02yie3qjSX8wA1Ek=.5cb20f20-ab61-4c0c-8f6b-ca9abceb0ad6@github.com>

On Tue, 23 Dec 2025 07:33:14 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> Good idea. There is a `Linker.Option.captureCallState("errno")` feature and I'll see how to use it.
>
> It looks like there has been prior work with this, at least with macos, e.g.: src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/errno_h.java

Also, there is a class `jdk.internal.foreign.CaptureStateUtil` that can be used to simplify and improve performance when working with `errno` and the likes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2667535314

From pminborg at openjdk.org  Wed Jan  7 08:42:56 2026
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 Jan 2026 08:42:56 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
Message-ID: <KVqg7r8bFUy2bHWuEDqVbuXhun4J5nSFRVvNjz0-Nlg=.f81cf4c3-c318-4bac-a8e6-72ae90269fd0@github.com>

On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   must have username; more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:

> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
> 87: 
> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();

Would it be a good idea to use capitalized names for immutable static fields in all places in the class? E.g., `CAPTURED_STATE_LAYOUT` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2667524583

From mdoerr at openjdk.org  Wed Jan  7 11:47:37 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 Jan 2026 11:47:37 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
Message-ID: <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>

On Mon, 5 Jan 2026 21:30:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664
>
> \What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)?

I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2668116234

From lkorinth at openjdk.org  Wed Jan  7 12:35:42 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:35:42 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
> 
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>    
>    Reviewed-by: aboldtch
>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>    
>    Reviewed-by: serb, aivanov, dnguyen
>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

I will redo the merge, I have done something strange.

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595

From lkorinth at openjdk.org  Wed Jan  7 12:58:43 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:58:43 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:

 - Merge branch '8373253' into 8367993
 - Merge branch 'master' into _8373253
 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

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

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02
  Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

PR: https://git.openjdk.org/jdk/pull/28723

From mcimadamore at openjdk.org  Wed Jan  7 13:28:33 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 7 Jan 2026 13:28:33 GMT
Subject: RFR: 8374718: Generation of CompilerProperties can fail in subtle ways
Message-ID: <Qtm3zAPwxSNXNSz0mV1-MQmEsikZsa9x59yX9iJVKuA=.5ceb2b92-8047-4129-9cb6-a61262bcd985@github.com>

[This PR](https://git.openjdk.org/jdk/pull/22553) introduced a new diagnostic info line to allow warning keys to be associated with a lint category. For instance:


# lint: identity
compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class=\
    attempt to synchronize on an instance of a value-based class


Is parsed at build time, and result in the following field to be added to the `CompilerProperties` class:


        /**
         * "attempt.to.synchronize.on.instance.of.value.based.class"
         */
        public static final LintWarning AttemptToSynchronizeOnInstanceOfValueBasedClass = new LintWarning(EnumSet.noneOf(DiagnosticFlag.class), LintCategory.get("identity").get(), "compiler", "attempt.to.synchronize.on.instance.of.value.based.class");


Note that the lint category undergoes a dynamic lookup:


LintCategory.get("identity").get()


This means that if there's a typo in the compiler.properties file, the lookup will fail and the JDK build will fail in a very obscure way (see JBS for reference). To avoid this problem, this PR removes the dynamic lookup from the generated file -- that is, the code in `CompilerProperties` will be:


        /**
         * "attempt.to.synchronize.on.instance.of.value.based.class"
         */
        public static final LintWarning AttemptToSynchronizeOnInstanceOfValueBasedClass = new LintWarning(EnumSet.noneOf(DiagnosticFlag.class), LintCategory.IDENTITY, "compiler", "attempt.to.synchronize.on.instance.of.value.based.class");


That is, the lint category string in `compiler.properties` is turned into a field name, first by capitalizing all the chars, then by replacing `-` with `_`. This ensures that if a lint category is mispelled in `compiler.prooprties`,  the resulting generated code will fail to compile.

The small price we have to pay for this is that we need to make sure that the naming of the lint category enum fields are consistent -- to this end the lint field `RAW` had to be renamed to `RAWTYPES`. But that was the only exception to the unwritten rule. I have also added a comment to capture this rule.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/29090/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29090&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374718
  Stats: 21 lines in 3 files changed: 13 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29090/head:pull/29090

PR: https://git.openjdk.org/jdk/pull/29090

From mbaesken at openjdk.org  Wed Jan  7 13:30:36 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Jan 2026 13:30:36 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted files
Message-ID: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>

We currently expect certain files in the bin and lib folders of the jdk image.
This should be checked by a test.
For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.

See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.

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

Commit messages:
 - Remove import
 - Remove some whitespace
 - For now, test debug too; AIX has also tzmappings file
 - JDK-8374471

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

PR: https://git.openjdk.org/jdk/pull/29040

From jlahoda at openjdk.org  Wed Jan  7 13:41:21 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Jan 2026 13:41:21 GMT
Subject: RFR: 8374718: Generation of CompilerProperties can fail in subtle
 ways
In-Reply-To: <Qtm3zAPwxSNXNSz0mV1-MQmEsikZsa9x59yX9iJVKuA=.5ceb2b92-8047-4129-9cb6-a61262bcd985@github.com>
References: <Qtm3zAPwxSNXNSz0mV1-MQmEsikZsa9x59yX9iJVKuA=.5ceb2b92-8047-4129-9cb6-a61262bcd985@github.com>
Message-ID: <GdXvlHICi9ghZWGlfuv3R3dmfGc9IK3ppNQHuGjn34M=.ff79b3c0-3d1f-458f-bc96-c3ddf877e1a0@github.com>

On Wed, 7 Jan 2026 13:17:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> [This PR](https://git.openjdk.org/jdk/pull/22553) introduced a new diagnostic info line to allow warning keys to be associated with a lint category. For instance:
> 
> 
> # lint: identity
> compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class=\
>     attempt to synchronize on an instance of a value-based class
> 
> 
> Is parsed at build time, and result in the following field to be added to the `CompilerProperties` class:
> 
> 
>         /**
>          * "attempt.to.synchronize.on.instance.of.value.based.class"
>          */
>         public static final LintWarning AttemptToSynchronizeOnInstanceOfValueBasedClass = new LintWarning(EnumSet.noneOf(DiagnosticFlag.class), LintCategory.get("identity").get(), "compiler", "attempt.to.synchronize.on.instance.of.value.based.class");
> 
> 
> Note that the lint category undergoes a dynamic lookup:
> 
> 
> LintCategory.get("identity").get()
> 
> 
> This means that if there's a typo in the compiler.properties file, the lookup will fail and the JDK build will fail in a very obscure way (see JBS for reference). To avoid this problem, this PR removes the dynamic lookup from the generated file -- that is, the code in `CompilerProperties` will be:
> 
> 
>         /**
>          * "attempt.to.synchronize.on.instance.of.value.based.class"
>          */
>         public static final LintWarning AttemptToSynchronizeOnInstanceOfValueBasedClass = new LintWarning(EnumSet.noneOf(DiagnosticFlag.class), LintCategory.IDENTITY, "compiler", "attempt.to.synchronize.on.instance.of.value.based.class");
> 
> 
> That is, the lint category string in `compiler.properties` is turned into a field name, first by capitalizing all the chars, then by replacing `-` with `_`. This ensures that if a lint category is mispelled in `compiler.prooprties`,  the resulting generated code will fail to compile.
> 
> The small price we have to pay for this is that we need to make sure that the naming of the lint category enum fields are consistent -- to this end the lint field `RAW` had to be renamed to `RAWTYPES`. But that was the only exception to the unwritten rule. I have also added a comment to capture this rule.

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29090#pullrequestreview-3634945680

From mcimadamore at openjdk.org  Wed Jan  7 14:10:02 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 7 Jan 2026 14:10:02 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
Message-ID: <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>

On Wed, 7 Jan 2026 11:44:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> \What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)?
>
> I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected.

> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?

Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here:

https://bugs.openjdk.org/browse/JDK-8336664

(apologies -- this link was already shared by @dmlloyd )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2668596071

From erikj at openjdk.org  Wed Jan  7 14:33:16 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 7 Jan 2026 14:33:16 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <EJi9oEYHMx2-ijbRgFt22PjMrAfJdgHlyKz1hY5kVWg=.ca9f9db8-eb91-4265-bd8a-7d7a76ce9ebc@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
 <EJi9oEYHMx2-ijbRgFt22PjMrAfJdgHlyKz1hY5kVWg=.ca9f9db8-eb91-4265-bd8a-7d7a76ce9ebc@github.com>
Message-ID: <brK78OcvqshrrESoqeo4JffpCvsbAPJbBStdGRB6DRI=.de01a151-4433-4613-9aa0-d5348995f60c@github.com>

On Wed, 7 Jan 2026 06:56:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Thanks for reviews! I am thinking to align the option name with current `--with-native-debug-symbols` better, since it is really about those. How about this?

Yes, that looks even better.

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3719142824

From erikj at openjdk.org  Wed Jan  7 14:48:48 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 7 Jan 2026 14:48:48 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files
In-Reply-To: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
Message-ID: <KLWMxALz7H5fEgqUkyTbcdvlw-w-l0jiph1wB_8AD6E=.4d312f79-3b04-4e05-bd44-d9208dfa926d@github.com>

On Mon, 5 Jan 2026 15:51:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently expect certain files in the bin and lib folders of the jdk image.
> This should be checked by a test.
> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
> 
> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.

The name of the test is rather vague. Is your plan to expand this to check more kinds of files in the near future? Otherwise I would like a more specific test name to avoid confusion. We are specifically checking bin and lib files in the JDK image.

Also, please be ready to followup on this if corner cases are discovered for specific build configurations. Typically a test like this that makes assumptions on the layout or contents of the image will need some amount of conditionals based on the build configuration. There is a framework for this in place in case you need it. I'm thinking about various kinds of instrumented builds that may create additional files in the image.

test/jdk/build/CheckFiles.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2026, Oracle and/or its affiliates. All rights reserved.

This file was added this year, so the copyright shouldn't state 2019.

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

PR Review: https://git.openjdk.org/jdk/pull/29040#pullrequestreview-3635195433
PR Review Comment: https://git.openjdk.org/jdk/pull/29040#discussion_r2668712020

From mbaesken at openjdk.org  Wed Jan  7 14:59:24 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Jan 2026 14:59:24 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files
In-Reply-To: <KLWMxALz7H5fEgqUkyTbcdvlw-w-l0jiph1wB_8AD6E=.4d312f79-3b04-4e05-bd44-d9208dfa926d@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <KLWMxALz7H5fEgqUkyTbcdvlw-w-l0jiph1wB_8AD6E=.4d312f79-3b04-4e05-bd44-d9208dfa926d@github.com>
Message-ID: <R83sptDY-ATbI83bAkKTVL9tc2gxg-nWHKFYlj9-QtY=.720f267f-18d1-4ce0-898d-e1aba721976d@github.com>

On Wed, 7 Jan 2026 14:46:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The name of the test is rather vague. Is your plan to expand this to check more kinds of files in the near future? Otherwise I would like a more specific test name to avoid confusion. We are specifically checking bin and lib files in the JDK image.
> 
> Also, please be ready to followup on this if corner cases are discovered for specific build configurations. Typically a test like this that makes assumptions on the layout or contents of the image will need some amount of conditionals based on the build configuration. There is a framework for this in place in case you need it. I'm thinking about various kinds of instrumented builds that may create additional files in the image.


I have at least some ideas to add more checks.  E.g. if an include  folder is present in the image , it should contain just headers.

If a legal folder is present, there is also only a rather limited number of files 'allowed' .

Regarding corner, cases - yes sure there can be some; maybe we need followup actions to handle them.

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

PR Comment: https://git.openjdk.org/jdk/pull/29040#issuecomment-3719252450

From mbaesken at openjdk.org  Wed Jan  7 15:29:00 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Jan 2026 15:29:00 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v2]
In-Reply-To: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
Message-ID: <d_HZqL-zzugdmvFTJnie-bKxeDTFFFauBnFNe4GI_Cw=.3e0a54e9-0a6e-40de-b3d8-071c75ae3d88@github.com>

> We currently expect certain files in the bin and lib folders of the jdk image.
> This should be checked by a test.
> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
> 
> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust COPYRIGHT year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29040/files
  - new: https://git.openjdk.org/jdk/pull/29040/files/5a76c542..88cee566

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

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

PR: https://git.openjdk.org/jdk/pull/29040

From mbaesken at openjdk.org  Wed Jan  7 15:37:05 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Jan 2026 15:37:05 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v2]
In-Reply-To: <d_HZqL-zzugdmvFTJnie-bKxeDTFFFauBnFNe4GI_Cw=.3e0a54e9-0a6e-40de-b3d8-071c75ae3d88@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <d_HZqL-zzugdmvFTJnie-bKxeDTFFFauBnFNe4GI_Cw=.3e0a54e9-0a6e-40de-b3d8-071c75ae3d88@github.com>
Message-ID: <F0lX1M27khv1CNIhCe6Q5oQrCNlyQOJaEXT7rdEXpYg=.4a935d0f-322d-4b7d-a213-cc5c64363cd0@github.com>

On Wed, 7 Jan 2026 15:29:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect certain files in the bin and lib folders of the jdk image.
>> This should be checked by a test.
>> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT year

Btw. I thought about limiting the test to ` !vm.debug`  ; we and probably most (if not all) vendors ship product JDKs so checking on debug  builds is probably much less important .

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

PR Comment: https://git.openjdk.org/jdk/pull/29040#issuecomment-3719451019

From shade at openjdk.org  Wed Jan  7 18:12:52 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 18:12:52 GMT
Subject: Integrated: 8374521: Support fine-grained native debug levels
In-Reply-To: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
Message-ID: <Y2vsSd9rf1CnHNnCYvVlKbC-EOOCfq02kCNVHEU3DbE=.49ba96db-5a91-48f5-a89f-69446ce4f593@github.com>

On Tue, 6 Jan 2026 08:28:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
> 
> Allowing users to configure the debug level allows two major deviations from the default level (2):
>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>  level=3: add even more debugging info, like macro expansion, into the debug data
> 
> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
> 
> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
> 
> I am open for bikeshedding on the option name :)

This pull request has now been integrated.

Changeset: dd20e915
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd20e9150666f247af61dfa524a170ef7dd96c03
Stats:     27 lines in 5 files changed: 23 ins; 0 del; 4 mod

8374521: Support fine-grained native debug levels

Reviewed-by: erikj, krk, clanger

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

PR: https://git.openjdk.org/jdk/pull/29056

From shade at openjdk.org  Wed Jan  7 18:12:49 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 18:12:49 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <c00GsobUOjf1M3CNqztG-SAOXh189Q-Hs7Gngi3YimQ=.1c25d1e6-9e77-4348-91e3-cc3f909368a5@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

Thanks! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3720110179

From erikj at openjdk.org  Wed Jan  7 18:30:09 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 7 Jan 2026 18:30:09 GMT
Subject: RFR: 8374642: EscapeHash macro fails with GNU make 4.3 and 4.4
Message-ID: <BM_98VMy1cifcpZ8XruZROlbNzLrwH6LETzwlmcwJJg=.70949df8-8a46-4aaf-aa84-61ce6a145d31@github.com>

The utility macro `EscapeHash` in Utils.gmk fails when running with GNU make 4.3 and 4.4. The issue seems to be fixed in 4.4.1 where it succeeds again. This failure can be observed by running the vardep tests using:


make test-make-make-base


I managed to figure out a workaround to make the macro work on these make versions, by referencing the hash character indirectly. With this fix, the test succeeds with at least GNU make 4.0, 4.2, 4.3, 4.4 and 4.4.1.

It's not clear if there is any part of the build that currently relies on this macro. This test was modified to include this check a long time ago in JDK 9 when the docs build was rewritten.

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

Commit messages:
 - JDK-8374642

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

PR: https://git.openjdk.org/jdk/pull/29097

From tbell at openjdk.org  Wed Jan  7 18:45:46 2026
From: tbell at openjdk.org (Tim Bell)
Date: Wed, 7 Jan 2026 18:45:46 GMT
Subject: RFR: 8374642: EscapeHash macro fails with GNU make 4.3 and 4.4
In-Reply-To: <BM_98VMy1cifcpZ8XruZROlbNzLrwH6LETzwlmcwJJg=.70949df8-8a46-4aaf-aa84-61ce6a145d31@github.com>
References: <BM_98VMy1cifcpZ8XruZROlbNzLrwH6LETzwlmcwJJg=.70949df8-8a46-4aaf-aa84-61ce6a145d31@github.com>
Message-ID: <R3Vxjzp-cMLgelKTCrTMB2uKggJIiQb36hfRw7axzMU=.aea3e024-34ae-43a4-92c6-a45dca4ebcad@github.com>

On Wed, 7 Jan 2026 18:23:30 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The utility macro `EscapeHash` in Utils.gmk fails when running with GNU make 4.3 and 4.4. The issue seems to be fixed in 4.4.1 where it succeeds again. This failure can be observed by running the vardep tests using:
> 
> 
> make test-make-make-base
> 
> 
> I managed to figure out a workaround to make the macro work on these make versions, by referencing the hash character indirectly. With this fix, the test succeeds with at least GNU make 4.0, 4.2, 4.3, 4.4 and 4.4.1.
> 
> It's not clear if there is any part of the build that currently relies on this macro. This test was modified to include this check a long time ago in JDK 9 when the docs build was rewritten.

Very good

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

Marked as reviewed by tbell (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29097#pullrequestreview-3636307296

From shade at openjdk.org  Wed Jan  7 18:49:57 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 18:49:57 GMT
Subject: RFR: 8374642: EscapeHash macro fails with GNU make 4.3 and 4.4
In-Reply-To: <BM_98VMy1cifcpZ8XruZROlbNzLrwH6LETzwlmcwJJg=.70949df8-8a46-4aaf-aa84-61ce6a145d31@github.com>
References: <BM_98VMy1cifcpZ8XruZROlbNzLrwH6LETzwlmcwJJg=.70949df8-8a46-4aaf-aa84-61ce6a145d31@github.com>
Message-ID: <STY39SPkfV2XdOjJIdGPX8pVQns4T_t46PbcFCh78TQ=.ae03aa6c-d2e7-45e9-a9cb-ac57a0c64ab4@github.com>

On Wed, 7 Jan 2026 18:23:30 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The utility macro `EscapeHash` in Utils.gmk fails when running with GNU make 4.3 and 4.4. The issue seems to be fixed in 4.4.1 where it succeeds again. This failure can be observed by running the vardep tests using:
> 
> 
> make test-make-make-base
> 
> 
> I managed to figure out a workaround to make the macro work on these make versions, by referencing the hash character indirectly. With this fix, the test succeeds with at least GNU make 4.0, 4.2, 4.3, 4.4 and 4.4.1.
> 
> It's not clear if there is any part of the build that currently relies on this macro. This test was modified to include this check a long time ago in JDK 9 when the docs build was rewritten.

Looks reasonable, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29097#pullrequestreview-3636335535

From erikj at openjdk.org  Wed Jan  7 19:29:34 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 7 Jan 2026 19:29:34 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v2]
In-Reply-To: <F0lX1M27khv1CNIhCe6Q5oQrCNlyQOJaEXT7rdEXpYg=.4a935d0f-322d-4b7d-a213-cc5c64363cd0@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <d_HZqL-zzugdmvFTJnie-bKxeDTFFFauBnFNe4GI_Cw=.3e0a54e9-0a6e-40de-b3d8-071c75ae3d88@github.com>
 <F0lX1M27khv1CNIhCe6Q5oQrCNlyQOJaEXT7rdEXpYg=.4a935d0f-322d-4b7d-a213-cc5c64363cd0@github.com>
Message-ID: <IwD6Pa68ErkOdNszpLSL19CncwbAmNp8s40-Rn-vF18=.fd88bba4-28e2-422b-a58e-db8620383240@github.com>

On Wed, 7 Jan 2026 15:33:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Btw. I thought about limiting the test to ` !vm.debug` ; we and probably most (if not all) vendors ship product JDKs so checking on debug builds is probably much less important .

Yes, that would definitely make sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/29040#issuecomment-3720422130

From clanger at openjdk.org  Wed Jan  7 21:11:36 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 7 Jan 2026 21:11:36 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <hFQryYSSxkMN0NSnBUSXTfNGw5vtfl0Txuvse96vboc=.fdc249b5-f52a-49b0-9c44-c497d2f3fb2e@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

> Thanks! Here goes.
> 
> /integrate

OK, no `--with-native-debug-symbols-level` then?

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3720816408

From ascarpino at openjdk.org  Wed Jan  7 21:18:30 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 7 Jan 2026 21:18:30 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
Message-ID: <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com>

On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   must have username; more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:

> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
> 87: 
> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();

Should the variables below be capitalized because they are `static final`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2666736772

From weijun at openjdk.org  Wed Jan  7 21:18:33 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Jan 2026 21:18:33 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <KVqg7r8bFUy2bHWuEDqVbuXhun4J5nSFRVvNjz0-Nlg=.f81cf4c3-c318-4bac-a8e6-72ae90269fd0@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
 <KVqg7r8bFUy2bHWuEDqVbuXhun4J5nSFRVvNjz0-Nlg=.f81cf4c3-c318-4bac-a8e6-72ae90269fd0@github.com>
Message-ID: <LfbtFPz67AFDPj90yWAOhJD_FBW6KYnlKGMvBDFZUSQ=.ddc5a010-9534-4be8-964b-e337d2a609bf@github.com>

On Wed, 7 Jan 2026 08:35:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   must have username; more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:
> 
>> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
>> 87: 
>> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
> 
> Would it be a good idea to use capitalized names for immutable static fields in all places in the class? E.g., `CAPTURED_STATE_LAYOUT` here.

Sure, I can use `CAPTURED_STATE_LAYOUT` and `ERRNO_HANDLE`. Do you also want me to capitalize those `MethodHandle`s, `pw_xyz_layout`, and `pw_xyz_offset`? I'll be happy to do so if we want to keep this tradition. I was looking into `HBShaper` and it's mixed there. The `jextract` output puts every constant behind a method and avoids this awkwardness.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2670096071

From weijun at openjdk.org  Wed Jan  7 21:50:50 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Jan 2026 21:50:50 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
 <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com>
Message-ID: <U6E7zbKhRYpSWOOyne6DBnZdpWanVKaBhL92x37En90=.91db86db-b6b7-40b4-b4bb-f711c96c3ee5@github.com>

On Wed, 7 Jan 2026 01:01:52 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   must have username; more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:
> 
>> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
>> 87: 
>> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
> 
> Should the variables below be capitalized because they are `static final`?

Per asked the same above. I'm not exactly sure if all of them should be capitalized. I'll willing to choose either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2670175161

From erikj at openjdk.org  Wed Jan  7 21:54:34 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 7 Jan 2026 21:54:34 GMT
Subject: Integrated: 8374642: EscapeHash macro fails with GNU make 4.3 and 4.4
In-Reply-To: <BM_98VMy1cifcpZ8XruZROlbNzLrwH6LETzwlmcwJJg=.70949df8-8a46-4aaf-aa84-61ce6a145d31@github.com>
References: <BM_98VMy1cifcpZ8XruZROlbNzLrwH6LETzwlmcwJJg=.70949df8-8a46-4aaf-aa84-61ce6a145d31@github.com>
Message-ID: <6Fw_S8tABn0H2_yBXEkLFdaT79LJI4mOHCDEt4a1Kxc=.4f61622f-41f6-41bf-8fb1-6df6ba51b37f@github.com>

On Wed, 7 Jan 2026 18:23:30 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The utility macro `EscapeHash` in Utils.gmk fails when running with GNU make 4.3 and 4.4. The issue seems to be fixed in 4.4.1 where it succeeds again. This failure can be observed by running the vardep tests using:
> 
> 
> make test-make-make-base
> 
> 
> I managed to figure out a workaround to make the macro work on these make versions, by referencing the hash character indirectly. With this fix, the test succeeds with at least GNU make 4.0, 4.2, 4.3, 4.4 and 4.4.1.
> 
> It's not clear if there is any part of the build that currently relies on this macro. This test was modified to include this check a long time ago in JDK 9 when the docs build was rewritten.

This pull request has now been integrated.

Changeset: 383fe1ef
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/383fe1efc3a23385b8576e20f458f91085c6325e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8374642: EscapeHash macro fails with GNU make 4.3 and 4.4

Reviewed-by: tbell, shade

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

PR: https://git.openjdk.org/jdk/pull/29097

From erikj at openjdk.org  Wed Jan  7 22:05:07 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 7 Jan 2026 22:05:07 GMT
Subject: [jdk26] RFR: 8374642: EscapeHash macro fails with GNU make 4.3 and 4.4
Message-ID: <8t9u3WmTnF4Owh55ZN75M1MpxDyQzUfu6R1_zBsH7lg=.c8eb8ce6-85a8-48df-9655-8d9e8f6f7513@github.com>

This pull request contains a backport of commit [383fe1ef](https://github.com/openjdk/jdk/commit/383fe1efc3a23385b8576e20f458f91085c6325e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Erik Joelsson on 7 Jan 2026 and was reviewed by Tim Bell and Aleksey Shipilev.

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

Commit messages:
 - Backport 383fe1efc3a23385b8576e20f458f91085c6325e

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

PR: https://git.openjdk.org/jdk/pull/29099

From shade at openjdk.org  Wed Jan  7 22:11:24 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Jan 2026 22:11:24 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <hFQryYSSxkMN0NSnBUSXTfNGw5vtfl0Txuvse96vboc=.fdc249b5-f52a-49b0-9c44-c497d2f3fb2e@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
 <hFQryYSSxkMN0NSnBUSXTfNGw5vtfl0Txuvse96vboc=.fdc249b5-f52a-49b0-9c44-c497d2f3fb2e@github.com>
Message-ID: <CWaSuRD8yZQgEbcUvuUoEMKQrrKo1BPoSqPxS3BSDc0=.ac117753-f3a6-4e8b-a211-dacad4d8ee12@github.com>

On Wed, 7 Jan 2026 21:07:41 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > Thanks! Here goes.
> > /integrate
> 
> OK, no `--with-native-debug-symbols-level` then?

Dang. I have not pushed my local commit! Argh. I'll follow up with the update tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3721004444

From mikael at openjdk.org  Thu Jan  8 01:46:38 2026
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 8 Jan 2026 01:46:38 GMT
Subject: [jdk26] RFR: 8374642: EscapeHash macro fails with GNU make 4.3 and
 4.4
In-Reply-To: <8t9u3WmTnF4Owh55ZN75M1MpxDyQzUfu6R1_zBsH7lg=.c8eb8ce6-85a8-48df-9655-8d9e8f6f7513@github.com>
References: <8t9u3WmTnF4Owh55ZN75M1MpxDyQzUfu6R1_zBsH7lg=.c8eb8ce6-85a8-48df-9655-8d9e8f6f7513@github.com>
Message-ID: <o0Cu6Vtt5WR7S-3CRqivvp0pQaEeD4-3dda_b7lKKMk=.4436decf-cfae-4b13-9b1e-cc38b5818493@github.com>

On Wed, 7 Jan 2026 21:57:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This pull request contains a backport of commit [383fe1ef](https://github.com/openjdk/jdk/commit/383fe1efc3a23385b8576e20f458f91085c6325e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Erik Joelsson on 7 Jan 2026 and was reviewed by Tim Bell and Aleksey Shipilev.

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29099#pullrequestreview-3637389626

From iris at openjdk.org  Thu Jan  8 01:55:09 2026
From: iris at openjdk.org (Iris Clark)
Date: Thu, 8 Jan 2026 01:55:09 GMT
Subject: [jdk26] RFR: 8374642: EscapeHash macro fails with GNU make 4.3 and
 4.4
In-Reply-To: <8t9u3WmTnF4Owh55ZN75M1MpxDyQzUfu6R1_zBsH7lg=.c8eb8ce6-85a8-48df-9655-8d9e8f6f7513@github.com>
References: <8t9u3WmTnF4Owh55ZN75M1MpxDyQzUfu6R1_zBsH7lg=.c8eb8ce6-85a8-48df-9655-8d9e8f6f7513@github.com>
Message-ID: <qp6J1oFBweGBcBAftH93fbInCY43_QwKYlICxBLB3Kk=.161942c7-9072-4248-8f19-53287951e51b@github.com>

On Wed, 7 Jan 2026 21:57:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This pull request contains a backport of commit [383fe1ef](https://github.com/openjdk/jdk/commit/383fe1efc3a23385b8576e20f458f91085c6325e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Erik Joelsson on 7 Jan 2026 and was reviewed by Tim Bell and Aleksey Shipilev.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29099#pullrequestreview-3637400553

From dholmes at openjdk.org  Thu Jan  8 05:59:31 2026
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jan 2026 05:59:31 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files
In-Reply-To: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
Message-ID: <S8Bj1t29cwg6DpYGpD_Ws1VEbfYAeVKaoPyisASaiHU=.a0142632-4eda-4101-91c4-934cc54bee05@github.com>

On Thu, 8 Jan 2026 05:18:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the jtreg failure handler that we use in the JDK? As noted in https://bugs.openjdk.org/browse/JDK-8374754 this change addresses the HTML rendering issues that are noticed in certain setups. The change here moves the inline javascript to a file of its own (generated as and when necessary).

test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlPage.java line 65:

> 63:         this.writer = new PrintWriter(fileWriter, true);
> 64:         createScriptFile(dir);
> 65:         createStyleSheetFile(dir);

Won't this create/overwrite the files each time one of the artifact pages (cores.html, processes.html etc) get created? Don't we just want to create one copy of these files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29106#discussion_r2670968504

From jpai at openjdk.org  Thu Jan  8 06:06:41 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Jan 2026 06:06:41 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files
In-Reply-To: <S8Bj1t29cwg6DpYGpD_Ws1VEbfYAeVKaoPyisASaiHU=.a0142632-4eda-4101-91c4-934cc54bee05@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <S8Bj1t29cwg6DpYGpD_Ws1VEbfYAeVKaoPyisASaiHU=.a0142632-4eda-4101-91c4-934cc54bee05@github.com>
Message-ID: <BFmIcvWRXNvh_NakmRs0My7JvYVWxsnzTlRtI9BMSOo=.0894ec04-3986-402a-9782-7d810e574416@github.com>

On Thu, 8 Jan 2026 05:54:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Can I please get a review of this change to the jtreg failure handler that we use in the JDK? As noted in https://bugs.openjdk.org/browse/JDK-8374754 this change addresses the HTML rendering issues that are noticed in certain setups. The change here moves the inline javascript to a file of its own (generated as and when necessary).
>
> test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlPage.java line 65:
> 
>> 63:         this.writer = new PrintWriter(fileWriter, true);
>> 64:         createScriptFile(dir);
>> 65:         createStyleSheetFile(dir);
> 
> Won't this create/overwrite the files each time one of the artifact pages (cores.html, processes.html etc) get created? Don't we just want to create one copy of these files.

It will yes. In an initial version I had a check to only create those files if not already present in that directory. I removed that check because each time I updated the script content in the java source code, I had to then manually delete these files from the local JTwork directory hierarchy, for that new content to be written to them in the subsequent jtreg run. 

With this code now stabilized, I think that check can be introduced back. I will update this PR shortly with that change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29106#discussion_r2670984401

From jpai at openjdk.org  Thu Jan  8 06:54:50 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Jan 2026 06:54:50 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
Message-ID: <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>

> Can I please get a review of this change to the jtreg failure handler that we use in the JDK? As noted in https://bugs.openjdk.org/browse/JDK-8374754 this change addresses the HTML rendering issues that are noticed in certain setups. The change here moves the inline javascript to a file of its own (generated as and when necessary).

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  create the script and css files only if not already present

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29106/files
  - new: https://git.openjdk.org/jdk/pull/29106/files/2ce710f1..dfda18c6

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

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

PR: https://git.openjdk.org/jdk/pull/29106

From jpai at openjdk.org  Thu Jan  8 06:54:52 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Jan 2026 06:54:52 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <BFmIcvWRXNvh_NakmRs0My7JvYVWxsnzTlRtI9BMSOo=.0894ec04-3986-402a-9782-7d810e574416@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <S8Bj1t29cwg6DpYGpD_Ws1VEbfYAeVKaoPyisASaiHU=.a0142632-4eda-4101-91c4-934cc54bee05@github.com>
 <BFmIcvWRXNvh_NakmRs0My7JvYVWxsnzTlRtI9BMSOo=.0894ec04-3986-402a-9782-7d810e574416@github.com>
Message-ID: <jZCJM93-iq97MsfWxo71vQGGjX4-JGOBSln7-fngpNc=.188fe167-87e5-4a7e-8f2f-60d698ed8025@github.com>

On Thu, 8 Jan 2026 06:02:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlPage.java line 65:
>> 
>>> 63:         this.writer = new PrintWriter(fileWriter, true);
>>> 64:         createScriptFile(dir);
>>> 65:         createStyleSheetFile(dir);
>> 
>> Won't this create/overwrite the files each time one of the artifact pages (cores.html, processes.html etc) get created? Don't we just want to create one copy of these files.
>
> It will yes. In an initial version I had a check to only create those files if not already present in that directory. I removed that check because each time I updated the script content in the java source code, I had to then manually delete these files from the local JTwork directory hierarchy, for that new content to be written to them in the subsequent jtreg run. 
> 
> With this code now stabilized, I think that check can be introduced back. I will update this PR shortly with that change.

Done, I've updated the PR to add a check for the file existence. This change continues to work fine in my local testing. I'll run another round of CI test with this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29106#discussion_r2671098077

From djelinski at openjdk.org  Thu Jan  8 07:13:37 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 8 Jan 2026 07:13:37 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
Message-ID: <OEmWnj-m0J8HcDfVuCAjipiPqS1lSDma8ers8J3NGUs=.7a00859c-b03f-4e63-8354-a8aac177bd10@github.com>

On Thu, 8 Jan 2026 06:54:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change to the jtreg failure handler that we use in the JDK? As noted in https://bugs.openjdk.org/browse/JDK-8374754 this change addresses the HTML rendering issues that are noticed in certain setups. The change here moves the inline javascript to a file of its own (generated as and when necessary).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   create the script and css files only if not already present

test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlPage.java line 96:

> 94:         }
> 95:         final String content = """
> 96:                 function doShow(e) {

Would it be possible to check in the css/js files to the repository instead of generating them on the fly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29106#discussion_r2671146941

From jpai at openjdk.org  Thu Jan  8 07:27:14 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Jan 2026 07:27:14 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <OEmWnj-m0J8HcDfVuCAjipiPqS1lSDma8ers8J3NGUs=.7a00859c-b03f-4e63-8354-a8aac177bd10@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
 <OEmWnj-m0J8HcDfVuCAjipiPqS1lSDma8ers8J3NGUs=.7a00859c-b03f-4e63-8354-a8aac177bd10@github.com>
Message-ID: <B4JhyJedf453A3LQnEdLirTnX98lSwgS5nWFKpgIMQI=.96a00673-f361-44ed-ae5f-d1538c311e39@github.com>

On Thu, 8 Jan 2026 07:11:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   create the script and css files only if not already present
>
> test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlPage.java line 96:
> 
>> 94:         }
>> 95:         final String content = """
>> 96:                 function doShow(e) {
> 
> Would it be possible to check in the css/js files to the repository instead of generating them on the fly?

Hello Daniel, that's possible to do. These files would then need to be looked up (ClassLoader.getResourceAsStream(...)) and then copied over to the relevant runtime `dir`(s) as and when needed by the failure handler. So there will still be a step of copying these files.

It does prevent the inline js/css text we have in these java source files. Is that inline script/css content you suggest we avoid (for better error detection and code completion in IDEs)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29106#discussion_r2671187017

From djelinski at openjdk.org  Thu Jan  8 07:40:30 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 8 Jan 2026 07:40:30 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <B4JhyJedf453A3LQnEdLirTnX98lSwgS5nWFKpgIMQI=.96a00673-f361-44ed-ae5f-d1538c311e39@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
 <OEmWnj-m0J8HcDfVuCAjipiPqS1lSDma8ers8J3NGUs=.7a00859c-b03f-4e63-8354-a8aac177bd10@github.com>
 <B4JhyJedf453A3LQnEdLirTnX98lSwgS5nWFKpgIMQI=.96a00673-f361-44ed-ae5f-d1538c311e39@github.com>
Message-ID: <CbGDuG3bQ4pV2g-qX-cUZq8dlmS0XnoNPhUeiklUECc=.c98fed92-ca55-4da3-a59f-ea6ee98a9438@github.com>

On Thu, 8 Jan 2026 07:25:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlPage.java line 96:
>> 
>>> 94:         }
>>> 95:         final String content = """
>>> 96:                 function doShow(e) {
>> 
>> Would it be possible to check in the css/js files to the repository instead of generating them on the fly?
>
> Hello Daniel, that's possible to do. These files would then need to be looked up (ClassLoader.getResourceAsStream(...)) and then copied over to the relevant runtime `dir`(s) as and when needed by the failure handler. So there will still be a step of copying these files.
> 
> It does prevent the inline js/css text we have in these java source files. Is that inline script/css content you suggest we avoid (for better error detection and code completion in IDEs)?

Yes. Having the js and css in separate files has several advantages: you can find the files using their file names, you have IDE support when editing, and if you fix a bug directly in the generated js file, you can copy the entire file instead of copying its contents back to the generator.

Not a blocker for this PR anyway; I don't expect anyone to work on these files anytime soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29106#discussion_r2671229107

From dholmes at openjdk.org  Thu Jan  8 07:40:30 2026
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jan 2026 07:40:30 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <CbGDuG3bQ4pV2g-qX-cUZq8dlmS0XnoNPhUeiklUECc=.c98fed92-ca55-4da3-a59f-ea6ee98a9438@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
 <OEmWnj-m0J8HcDfVuCAjipiPqS1lSDma8ers8J3NGUs=.7a00859c-b03f-4e63-8354-a8aac177bd10@github.com>
 <B4JhyJedf453A3LQnEdLirTnX98lSwgS5nWFKpgIMQI=.96a00673-f361-44ed-ae5f-d1538c311e39@github.com>
 <CbGDuG3bQ4pV2g-qX-cUZq8dlmS0XnoNPhUeiklUECc=.c98fed92-ca55-4da3-a59f-ea6ee98a9438@github.com>
Message-ID: <slWJjF5PNp4Sb-liJZQ_U3E5AEqVqPMlA3Ix9TuS8pE=.d6f41b5b-cddf-4418-94ec-a2686e2a4874@github.com>

On Thu, 8 Jan 2026 07:37:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hello Daniel, that's possible to do. These files would then need to be looked up (ClassLoader.getResourceAsStream(...)) and then copied over to the relevant runtime `dir`(s) as and when needed by the failure handler. So there will still be a step of copying these files.
>> 
>> It does prevent the inline js/css text we have in these java source files. Is that inline script/css content you suggest we avoid (for better error detection and code completion in IDEs)?
>
> Yes. Having the js and css in separate files has several advantages: you can find the files using their file names, you have IDE support when editing, and if you fix a bug directly in the generated js file, you can copy the entire file instead of copying its contents back to the generator.
> 
> Not a blocker for this PR anyway; I don't expect anyone to work on these files anytime soon.

I think that would overcomplicate things for the various "failure" handlers ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29106#discussion_r2671231299

From shade at openjdk.org  Thu Jan  8 08:11:40 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jan 2026 08:11:40 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <CWaSuRD8yZQgEbcUvuUoEMKQrrKo1BPoSqPxS3BSDc0=.ac117753-f3a6-4e8b-a211-dacad4d8ee12@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
 <hFQryYSSxkMN0NSnBUSXTfNGw5vtfl0Txuvse96vboc=.fdc249b5-f52a-49b0-9c44-c497d2f3fb2e@github.com>
 <CWaSuRD8yZQgEbcUvuUoEMKQrrKo1BPoSqPxS3BSDc0=.ac117753-f3a6-4e8b-a211-dacad4d8ee12@github.com>
Message-ID: <hYIiE16z8ttje-DYPUzqtdLn5Z3_P3a7KTRbYD1byos=.10252d35-1ef9-4166-b177-91ea5afc609a@github.com>

On Wed, 7 Jan 2026 22:07:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Dang. I have not pushed my local commit! Argh. I'll follow up with the update tomorrow.

https://github.com/openjdk/jdk/pull/29108

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3722650726

From shade at openjdk.org  Thu Jan  8 08:14:07 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jan 2026 08:14:07 GMT
Subject: RFR: 8374767: Amend JDK-8374521 with new option name
Message-ID: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>

During [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) review we agreed on the new option name, but I forgot to push the commit that actually does it! So we integrated [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) with older option name. This should amend the change with proper option name.

The options are now:


  --with-native-debug-symbols-level
                          set the native debug symbol level (GCC and Clang only) [toolchain default]
  --with-native-debug-symbols
                          set the native debug symbol configuration (none,
                          internal, external, zipped) [varying]


Additional testing:
 - [ ] GHA

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

Commit messages:
 - --with-native-debug-symbols-level

Changes: https://git.openjdk.org/jdk/pull/29108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374767
  Stats: 18 lines in 5 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/29108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29108/head:pull/29108

PR: https://git.openjdk.org/jdk/pull/29108

From clanger at openjdk.org  Thu Jan  8 08:36:27 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 8 Jan 2026 08:36:27 GMT
Subject: RFR: 8374767: Amend JDK-8374521 with new option name
In-Reply-To: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>
References: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>
Message-ID: <272BnGd-VI_pwrcoVZW9TGdHkRbmdv77UwLgr9OJYXI=.08d93deb-03f4-4ce0-8df5-00410abbf5fe@github.com>

On Thu, 8 Jan 2026 08:07:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) review we agreed on the new option name, but I forgot to push the commit that actually does it! So we integrated [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) with older option name. This should amend the change with proper option name.
> 
> The options are now:
> 
> 
>   --with-native-debug-symbols-level
>                           set the native debug symbol level (GCC and Clang only) [toolchain default]
>   --with-native-debug-symbols
>                           set the native debug symbol configuration (none,
>                           internal, external, zipped) [varying]
> 
> 
> Additional testing:
>  - [ ] GHA

Looks correct.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29108#pullrequestreview-3638352145

From mbaesken at openjdk.org  Thu Jan  8 09:10:02 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 8 Jan 2026 09:10:02 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v3]
In-Reply-To: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
Message-ID: <byErdkUA4oREAzHhqyQl9zE7MrAkNQvg7uSMavYwij0=.166533f1-89de-48e7-97c8-6328a7cef3d7@github.com>

> We currently expect certain files in the bin and lib folders of the jdk image.
> This should be checked by a test.
> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
> 
> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Run the test only with product images

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29040/files
  - new: https://git.openjdk.org/jdk/pull/29040/files/88cee566..e00acbb1

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

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

PR: https://git.openjdk.org/jdk/pull/29040

From shade at openjdk.org  Thu Jan  8 09:21:44 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jan 2026 09:21:44 GMT
Subject: RFR: 8374767: Amend JDK-8374521 with new option name
In-Reply-To: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>
References: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>
Message-ID: <dfKhrvFkyd5u37eTmaTQyp-Jigz4JWFCKFpCBdpiZZk=.00fa1296-7338-4523-8a87-db5c89562540@github.com>

On Thu, 8 Jan 2026 08:07:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) review we agreed on the new option name, but I forgot to push the commit that actually does it! So we integrated [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) with older option name. This should amend the change with proper option name.
> 
> The options are now:
> 
> 
>   --with-native-debug-symbols-level
>                           set the native debug symbol level (GCC and Clang only) [toolchain default]
>   --with-native-debug-symbols
>                           set the native debug symbol configuration (none,
>                           internal, external, zipped) [varying]
> 
> 
> Additional testing:
>  - [ ] GHA

S390X build failure is due to https://github.com/openjdk/jdk/pull/29109

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

PR Comment: https://git.openjdk.org/jdk/pull/29108#issuecomment-3722947445

From jpai at openjdk.org  Thu Jan  8 09:41:12 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Jan 2026 09:41:12 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <slWJjF5PNp4Sb-liJZQ_U3E5AEqVqPMlA3Ix9TuS8pE=.d6f41b5b-cddf-4418-94ec-a2686e2a4874@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
 <OEmWnj-m0J8HcDfVuCAjipiPqS1lSDma8ers8J3NGUs=.7a00859c-b03f-4e63-8354-a8aac177bd10@github.com>
 <B4JhyJedf453A3LQnEdLirTnX98lSwgS5nWFKpgIMQI=.96a00673-f361-44ed-ae5f-d1538c311e39@github.com>
 <CbGDuG3bQ4pV2g-qX-cUZq8dlmS0XnoNPhUeiklUECc=.c98fed92-ca55-4da3-a59f-ea6ee98a9438@github.com>
 <slWJjF5PNp4Sb-liJZQ_U3E5AEqVqPMlA3Ix9TuS8pE=.d6f41b5b-cddf-4418-94ec-a2686e2a4874@github.com>
Message-ID: <PapdIvYF9sENBKF4NrtnU2Xme3jxnOp9dnBI30ephHI=.12d77895-cd56-42bc-b140-6a7f68553bcb@github.com>

On Thu, 8 Jan 2026 07:37:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes. Having the js and css in separate files has several advantages: you can find the files using their file names, you have IDE support when editing, and if you fix a bug directly in the generated js file, you can copy the entire file instead of copying its contents back to the generator.
>> 
>> Not a blocker for this PR anyway; I don't expect anyone to work on these files anytime soon.
>
> I think that would overcomplicate things for the various "failure" handlers ...

> Yes. Having the js and css in separate files has several advantages: you can find the files using their file names, you have IDE support when editing, and if you fix a bug directly in the generated js file

Understood.

> Not a blocker for this PR anyway; I don't expect anyone to work on these files anytime soon.

I agree that the changes to this code is going to be rare. I'll consider this suggestion of moving the content to a separate version controlled file for a future PR then. I would have tried it now, but there is one internal failure handler which I am not yet conversant with and I don't know if it will complicate things in that code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29106#discussion_r2671622490

From shade at openjdk.org  Thu Jan  8 09:47:41 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jan 2026 09:47:41 GMT
Subject: RFR: 8374767: Amend JDK-8374521 with new option name [v2]
In-Reply-To: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>
References: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>
Message-ID: <nJa_EcFtwQbkr61BQcNO4kjc8iEm59UdSM9KduXwfO4=.3712e549-4c04-42aa-97da-70b9887e79b4@github.com>

> During [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) review we agreed on the new option name, but I forgot to push the commit that actually does it! So we integrated [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) with older option name. This should amend the change with proper option name.
> 
> The options are now:
> 
> 
>   --with-native-debug-symbols-level
>                           set the native debug symbol level (GCC and Clang only) [toolchain default]
>   --with-native-debug-symbols
>                           set the native debug symbol configuration (none,
>                           internal, external, zipped) [varying]
> 
> 
> Additional testing:
>  - [ ] GHA

Aleksey Shipilev 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 'master' into JDK-8374767-debug-info-option-name
 - --with-native-debug-symbols-level

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29108/files
  - new: https://git.openjdk.org/jdk/pull/29108/files/bca06a1f..1219e013

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

  Stats: 47 lines in 5 files changed: 1 ins; 15 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/29108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29108/head:pull/29108

PR: https://git.openjdk.org/jdk/pull/29108

From mcimadamore at openjdk.org  Thu Jan  8 10:27:39 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Jan 2026 10:27:39 GMT
Subject: Integrated: 8374718: Generation of CompilerProperties can fail in
 subtle ways
In-Reply-To: <Qtm3zAPwxSNXNSz0mV1-MQmEsikZsa9x59yX9iJVKuA=.5ceb2b92-8047-4129-9cb6-a61262bcd985@github.com>
References: <Qtm3zAPwxSNXNSz0mV1-MQmEsikZsa9x59yX9iJVKuA=.5ceb2b92-8047-4129-9cb6-a61262bcd985@github.com>
Message-ID: <Kqxo7V06UJ1KiScAFks2Eh9aWzPbKep2oBhi2erW5CM=.20aa1dc4-ab1b-4d84-a8de-632e2d6b9f8e@github.com>

On Wed, 7 Jan 2026 13:17:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> [This PR](https://git.openjdk.org/jdk/pull/22553) introduced a new diagnostic info line to allow warning keys to be associated with a lint category. For instance:
> 
> 
> # lint: identity
> compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class=\
>     attempt to synchronize on an instance of a value-based class
> 
> 
> Is parsed at build time, and result in the following field to be added to the `CompilerProperties` class:
> 
> 
>         /**
>          * "attempt.to.synchronize.on.instance.of.value.based.class"
>          */
>         public static final LintWarning AttemptToSynchronizeOnInstanceOfValueBasedClass = new LintWarning(EnumSet.noneOf(DiagnosticFlag.class), LintCategory.get("identity").get(), "compiler", "attempt.to.synchronize.on.instance.of.value.based.class");
> 
> 
> Note that the lint category undergoes a dynamic lookup:
> 
> 
> LintCategory.get("identity").get()
> 
> 
> This means that if there's a typo in the compiler.properties file, the lookup will fail and the JDK build will fail in a very obscure way (see JBS for reference). To avoid this problem, this PR removes the dynamic lookup from the generated file -- that is, the code in `CompilerProperties` will be:
> 
> 
>         /**
>          * "attempt.to.synchronize.on.instance.of.value.based.class"
>          */
>         public static final LintWarning AttemptToSynchronizeOnInstanceOfValueBasedClass = new LintWarning(EnumSet.noneOf(DiagnosticFlag.class), LintCategory.IDENTITY, "compiler", "attempt.to.synchronize.on.instance.of.value.based.class");
> 
> 
> That is, the lint category string in `compiler.properties` is turned into a field name, first by capitalizing all the chars, then by replacing `-` with `_`. This ensures that if a lint category is mispelled in `compiler.prooprties`,  the resulting generated code will fail to compile.
> 
> The small price we have to pay for this is that we need to make sure that the naming of the lint category enum fields are consistent -- to this end the lint field `RAW` had to be renamed to `RAWTYPES`. But that was the only exception to the unwritten rule. I have also added a comment to capture this rule.

This pull request has now been integrated.

Changeset: 904ba5f5
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/904ba5f5ed7d3ac1a3606ff7532ba3c206a2d9b9
Stats:     21 lines in 3 files changed: 13 ins; 4 del; 4 mod

8374718: Generation of CompilerProperties can fail in subtle ways

Reviewed-by: jlahoda

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

PR: https://git.openjdk.org/jdk/pull/29090

From clanger at openjdk.org  Thu Jan  8 13:37:04 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 8 Jan 2026 13:37:04 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v3]
In-Reply-To: <byErdkUA4oREAzHhqyQl9zE7MrAkNQvg7uSMavYwij0=.166533f1-89de-48e7-97c8-6328a7cef3d7@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <byErdkUA4oREAzHhqyQl9zE7MrAkNQvg7uSMavYwij0=.166533f1-89de-48e7-97c8-6328a7cef3d7@github.com>
Message-ID: <Z2hWrwYUGiedpqAiUvAaXSSkiivwLpQ3YBOj_u136qg=.ca80ed71-1a2b-456b-9217-2e5e3adc4eaa@github.com>

On Thu, 8 Jan 2026 09:10:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect certain files in the bin and lib folders of the jdk image.
>> This should be checked by a test.
>> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Run the test only with product images

test/jdk/build/CheckFiles.java line 3:

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

You could use an SAP copyright here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29040#discussion_r2672376581

From mbaesken at openjdk.org  Thu Jan  8 13:47:29 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 8 Jan 2026 13:47:29 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v4]
In-Reply-To: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
Message-ID: <yWBYi3tN7-PtOYV6jMqxO3dPFJUeIXf-vxk-TUfN3BY=.eb837459-c3f4-4892-94a9-76f191555162@github.com>

> We currently expect certain files in the bin and lib folders of the jdk image.
> This should be checked by a test.
> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
> 
> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Add SAP copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29040/files
  - new: https://git.openjdk.org/jdk/pull/29040/files/e00acbb1..3f942c61

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

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

PR: https://git.openjdk.org/jdk/pull/29040

From mbaesken at openjdk.org  Thu Jan  8 14:18:11 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 8 Jan 2026 14:18:11 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v3]
In-Reply-To: <Z2hWrwYUGiedpqAiUvAaXSSkiivwLpQ3YBOj_u136qg=.ca80ed71-1a2b-456b-9217-2e5e3adc4eaa@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <byErdkUA4oREAzHhqyQl9zE7MrAkNQvg7uSMavYwij0=.166533f1-89de-48e7-97c8-6328a7cef3d7@github.com>
 <Z2hWrwYUGiedpqAiUvAaXSSkiivwLpQ3YBOj_u136qg=.ca80ed71-1a2b-456b-9217-2e5e3adc4eaa@github.com>
Message-ID: <sJ-nYA3pmc-Po1XtOJ9L_PD0dZu6Um1oXcK5I5nZI-Q=.f9889cb0-e138-4296-a315-83b0fd37b636@github.com>

On Thu, 8 Jan 2026 13:32:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Run the test only with product images
>
> test/jdk/build/CheckFiles.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> You could use an SAP copyright here

Makes Sense, I added it.
Btw. while at it, I noticed we still have the old 'SAP AG' entries in some files 

test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE78_A.java:2: * Copyright (c) 2018 by SAP AG, Walldorf, Germany.
test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE_Loader2.java:2: * Copyright (c) 2018 by SAP AG, Walldorf, Germany.
test/hotspot/jtreg/runtime/execstack/Test.java:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
test/hotspot/jtreg/runtime/execstack/TestMT.java:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
test/hotspot/jtreg/runtime/execstack/libtest-rw.c:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
test/hotspot/jtreg/runtime/execstack/libtest-rwx.c:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29040#discussion_r2672527597

From krk at openjdk.org  Thu Jan  8 17:00:22 2026
From: krk at openjdk.org (Kerem Kat)
Date: Thu, 8 Jan 2026 17:00:22 GMT
Subject: RFR: 8374767: Amend JDK-8374521 with new option name [v2]
In-Reply-To: <nJa_EcFtwQbkr61BQcNO4kjc8iEm59UdSM9KduXwfO4=.3712e549-4c04-42aa-97da-70b9887e79b4@github.com>
References: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>
 <nJa_EcFtwQbkr61BQcNO4kjc8iEm59UdSM9KduXwfO4=.3712e549-4c04-42aa-97da-70b9887e79b4@github.com>
Message-ID: <ON0hOw8YEZLH8qQ63GU87bEbRjE28BucnC81sDAoBtk=.81984b83-5646-4bca-9e8a-b8ce48f853c1@github.com>

On Thu, 8 Jan 2026 09:47:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) review we agreed on the new option name, but I forgot to push the commit that actually does it! So we integrated [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) with older option name. This should amend the change with proper option name.
>> 
>> The options are now:
>> 
>> 
>>   --with-native-debug-symbols-level
>>                           set the native debug symbol level (GCC and Clang only) [toolchain default]
>>   --with-native-debug-symbols
>>                           set the native debug symbol configuration (none,
>>                           internal, external, zipped) [varying]
>> 
>> 
>> Additional testing:
>>  - [ ] GHA
>
> Aleksey Shipilev 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 'master' into JDK-8374767-debug-info-option-name
>  - --with-native-debug-symbols-level

Marked as reviewed by krk (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/29108#pullrequestreview-3640344856

From shade at openjdk.org  Thu Jan  8 18:02:29 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jan 2026 18:02:29 GMT
Subject: RFR: 8374767: Amend JDK-8374521 with new option name [v2]
In-Reply-To: <nJa_EcFtwQbkr61BQcNO4kjc8iEm59UdSM9KduXwfO4=.3712e549-4c04-42aa-97da-70b9887e79b4@github.com>
References: <DCdBxxam-LV_s7JWRlRDJBjwFQmsu4sSQ-Wtq7CWOGQ=.e43599a2-56bb-49e2-87e7-51d0f6d63218@github.com>
 <nJa_EcFtwQbkr61BQcNO4kjc8iEm59UdSM9KduXwfO4=.3712e549-4c04-42aa-97da-70b9887e79b4@github.com>
Message-ID: <PpVV-Hc9dxQk7h8ZP_sHfTmWoY0vx6D6EJPp0RlU8nw=.e7fd6a81-7cf7-486b-8777-a757f6467ccc@github.com>

On Thu, 8 Jan 2026 09:47:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) review we agreed on the new option name, but I forgot to push the commit that actually does it! So we integrated [JDK-8374521](https://bugs.openjdk.org/browse/JDK-8374521) with older option name. This should amend the change with proper option name.
>> 
>> The options are now:
>> 
>> 
>>   --with-native-debug-symbols-level
>>                           set the native debug symbol level (GCC and Clang only) [toolchain default]
>>   --with-native-debug-symbols
>>                           set the native debug symbol configuration (none,
>>                           internal, external, zipped) [varying]
>> 
>> 
>> Additional testing:
>>  - [x] GHA
>
> Aleksey Shipilev 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 'master' into JDK-8374767-debug-info-option-name
>  - --with-native-debug-symbols-level

Thanks for reviews, here we go.

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

PR Comment: https://git.openjdk.org/jdk/pull/29108#issuecomment-3725019080

From erikj at openjdk.org  Thu Jan  8 18:04:05 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 8 Jan 2026 18:04:05 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
Message-ID: <K-AxrgFxZZRyQXJJLszF_1VzyIT3yCt17Ab2cUxwx3o=.0552acf0-d1dd-4097-86e6-6a8fb09d0031@github.com>

On Thu, 8 Jan 2026 06:54:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change to the jtreg failure handler that we use in the JDK? As noted in https://bugs.openjdk.org/browse/JDK-8374754 this change addresses the HTML rendering issues that are noticed in certain setups. The change here moves the inline javascript to a file of its own (generated as and when necessary).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   create the script and css files only if not already present

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29106#pullrequestreview-3640593223

From erikj at openjdk.org  Thu Jan  8 18:06:31 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 8 Jan 2026 18:06:31 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v4]
In-Reply-To: <yWBYi3tN7-PtOYV6jMqxO3dPFJUeIXf-vxk-TUfN3BY=.eb837459-c3f4-4892-94a9-76f191555162@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <yWBYi3tN7-PtOYV6jMqxO3dPFJUeIXf-vxk-TUfN3BY=.eb837459-c3f4-4892-94a9-76f191555162@github.com>
Message-ID: <AIiL67txdp740MRiTnogI3hpXpArcomgVnFrkUP4W0M=.5ba04de2-d023-4ad8-8d37-a0662a945be9@github.com>

On Thu, 8 Jan 2026 13:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect certain files in the bin and lib folders of the jdk image.
>> This should be checked by a test.
>> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add SAP copyright

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29040#pullrequestreview-3640600291

From erikj at openjdk.org  Thu Jan  8 18:16:36 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 8 Jan 2026 18:16:36 GMT
Subject: [jdk26] Integrated: 8374642: EscapeHash macro fails with GNU make 4.3
 and 4.4
In-Reply-To: <8t9u3WmTnF4Owh55ZN75M1MpxDyQzUfu6R1_zBsH7lg=.c8eb8ce6-85a8-48df-9655-8d9e8f6f7513@github.com>
References: <8t9u3WmTnF4Owh55ZN75M1MpxDyQzUfu6R1_zBsH7lg=.c8eb8ce6-85a8-48df-9655-8d9e8f6f7513@github.com>
Message-ID: <GB_SZ6jZ1_cpDWC-h9DNF0q2Iyk4zawqlqhX123vw_Y=.998086b0-ad32-4750-a027-3c444b277170@github.com>

On Wed, 7 Jan 2026 21:57:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This pull request contains a backport of commit [383fe1ef](https://github.com/openjdk/jdk/commit/383fe1efc3a23385b8576e20f458f91085c6325e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Erik Joelsson on 7 Jan 2026 and was reviewed by Tim Bell and Aleksey Shipilev.

This pull request has now been integrated.

Changeset: 09817940
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09817940f695ac09516b1d01779ba329e061feb8
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8374642: EscapeHash macro fails with GNU make 4.3 and 4.4

Reviewed-by: mikael, iris
Backport-of: 383fe1efc3a23385b8576e20f458f91085c6325e

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

PR: https://git.openjdk.org/jdk/pull/29099

From clanger at openjdk.org  Fri Jan  9 08:43:04 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 9 Jan 2026 08:43:04 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v4]
In-Reply-To: <yWBYi3tN7-PtOYV6jMqxO3dPFJUeIXf-vxk-TUfN3BY=.eb837459-c3f4-4892-94a9-76f191555162@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <yWBYi3tN7-PtOYV6jMqxO3dPFJUeIXf-vxk-TUfN3BY=.eb837459-c3f4-4892-94a9-76f191555162@github.com>
Message-ID: <QBNlU0Pei_3RG7od8KDjESX70aZJ-c98AXtJghSg-Cg=.004f9a63-6634-4b92-8212-0f5076abf59d@github.com>

On Thu, 8 Jan 2026 13:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect certain files in the bin and lib folders of the jdk image.
>> This should be checked by a test.
>> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add SAP copyright

LGTM

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29040#pullrequestreview-3642923901

From clanger at openjdk.org  Fri Jan  9 08:43:08 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 9 Jan 2026 08:43:08 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v3]
In-Reply-To: <sJ-nYA3pmc-Po1XtOJ9L_PD0dZu6Um1oXcK5I5nZI-Q=.f9889cb0-e138-4296-a315-83b0fd37b636@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <byErdkUA4oREAzHhqyQl9zE7MrAkNQvg7uSMavYwij0=.166533f1-89de-48e7-97c8-6328a7cef3d7@github.com>
 <Z2hWrwYUGiedpqAiUvAaXSSkiivwLpQ3YBOj_u136qg=.ca80ed71-1a2b-456b-9217-2e5e3adc4eaa@github.com>
 <sJ-nYA3pmc-Po1XtOJ9L_PD0dZu6Um1oXcK5I5nZI-Q=.f9889cb0-e138-4296-a315-83b0fd37b636@github.com>
Message-ID: <HhyZxGlKN_ZMcUVMOWSKTNWOA97zbUJ6J9P_NUBwfNE=.ef066113-49ca-4497-8c74-71a393fa083c@github.com>

On Thu, 8 Jan 2026 14:14:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/jdk/build/CheckFiles.java line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved.
>>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> 
>> You could use an SAP copyright here
>
> Makes Sense, I added it.
> Btw. while at it, I noticed we still have the old 'SAP AG' entries in some files 
> 
> test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE78_A.java:2: * Copyright (c) 2018 by SAP AG, Walldorf, Germany.
> test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE_Loader2.java:2: * Copyright (c) 2018 by SAP AG, Walldorf, Germany.
> test/hotspot/jtreg/runtime/execstack/Test.java:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
> test/hotspot/jtreg/runtime/execstack/TestMT.java:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
> test/hotspot/jtreg/runtime/execstack/libtest-rw.c:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
> test/hotspot/jtreg/runtime/execstack/libtest-rwx.c:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.

OK, that's something that should be cleaned up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29040#discussion_r2675322818

From sjohanss at openjdk.org  Fri Jan  9 08:47:01 2026
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 9 Jan 2026 08:47:01 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
Message-ID: <CNxPXaG8qXqVrPo5NsiiGa6M6r3hPE9UcLKaDYkr5is=.26f84708-d442-45b0-b787-fda252292bee@github.com>

On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:
> 
>  - Merge branch '8373253' into 8367993
>  - Merge branch 'master' into _8373253
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

Thanks for looking into this Leo. 

Overall I think it looks good, just some small questions and suggestions.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637:

> 1635: 
> 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const {
> 1637:   assert(_cm != nullptr, "thread must exist in order to check if mark is terminating");

I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427:

> 2425:   if (_cm->is_fully_initialized()) {
> 2426:     tc->do_thread(_cm->cm_thread());
> 2427:   }

Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()`

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549:

> 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) {
> 2548:   assert(!_cm->in_progress(), "Can not start concurrent operation while in progress");
> 2549:   assert(_cm->is_fully_initialized(), "sanity");

Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert.

src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46:

> 44:     return false;
> 45:   }
> 46: 

Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right?

src/hotspot/share/gc/g1/g1Policy.cpp line 744:

> 742:   if (!_g1h->concurrent_mark()->is_fully_initialized()) {
> 743:     return false;
> 744:   }

Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127:

> 1125: 
> 1126: void G1YoungCollector::collect() {
> 1127:   _g1h->_cm->fully_initialize();

I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)`

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630

From mbaesken at openjdk.org  Fri Jan  9 09:01:04 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Jan 2026 09:01:04 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v3]
In-Reply-To: <HhyZxGlKN_ZMcUVMOWSKTNWOA97zbUJ6J9P_NUBwfNE=.ef066113-49ca-4497-8c74-71a393fa083c@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <byErdkUA4oREAzHhqyQl9zE7MrAkNQvg7uSMavYwij0=.166533f1-89de-48e7-97c8-6328a7cef3d7@github.com>
 <Z2hWrwYUGiedpqAiUvAaXSSkiivwLpQ3YBOj_u136qg=.ca80ed71-1a2b-456b-9217-2e5e3adc4eaa@github.com>
 <sJ-nYA3pmc-Po1XtOJ9L_PD0dZu6Um1oXcK5I5nZI-Q=.f9889cb0-e138-4296-a315-83b0fd37b636@github.com>
 <HhyZxGlKN_ZMcUVMOWSKTNWOA97zbUJ6J9P_NUBwfNE=.ef066113-49ca-4497-8c74-71a393fa083c@github.com>
Message-ID: <1uOXtU1eLkVYFdNHebclSlLSTX7zJhHSkrIS4pRFf8w=.da0d721c-9502-463d-9fb7-eb97ab897f40@github.com>

On Fri, 9 Jan 2026 08:39:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Makes Sense, I added it.
>> Btw. while at it, I noticed we still have the old 'SAP AG' entries in some files 
>> 
>> test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE78_A.java:2: * Copyright (c) 2018 by SAP AG, Walldorf, Germany.
>> test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE_Loader2.java:2: * Copyright (c) 2018 by SAP AG, Walldorf, Germany.
>> test/hotspot/jtreg/runtime/execstack/Test.java:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
>> test/hotspot/jtreg/runtime/execstack/TestMT.java:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
>> test/hotspot/jtreg/runtime/execstack/libtest-rw.c:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
>> test/hotspot/jtreg/runtime/execstack/libtest-rwx.c:3: * Copyright (c) 2011 SAP AG.  All Rights Reserved.
>
> OK, that's something that should be cleaned up.

I opened
https://bugs.openjdk.org/browse/JDK-8374872
8374872: Cleanup outdated SAP AG copyright header info

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29040#discussion_r2675372104

From stefank at openjdk.org  Fri Jan  9 12:09:22 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 12:09:22 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
 <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
Message-ID: <aSHHOBAAdNFMkL3dy7qiMutT8mTtX0R5pLQU6kB4Diw=.38610782-7ad7-44f6-9d44-4cf8164b9562@github.com>

On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into _8367993
>>  - 8366058: Outdated comment in WinCAPISeedGenerator
>>    
>>    Reviewed-by: mullan
>>  - 8357258: x86: Improve receiver type profiling reliability
>>    
>>    Reviewed-by: kvn, vlivanov
>>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>>    
>>    Reviewed-by: lucy, jpai
>>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>>    
>>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>>    
>>    Reviewed-by: alanb, dholmes
>>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>>    
>>    Reviewed-by: kbarrett
>>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>>    
>>    Reviewed-by: djelinski, mpowers, ascarpino
>>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>>    
>>    Reviewed-by: aboldtch
>>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>>    
>>    Reviewed-by: serb, aivanov, dnguyen
>>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767
>
> I will redo the merge, I have done something strange.

@lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels?

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315

From jpai at openjdk.org  Fri Jan  9 16:10:22 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jan 2026 16:10:22 GMT
Subject: RFR: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files [v2]
In-Reply-To: <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
 <W9ubhRkrJ33Fz5_yRIM7LHtt12rY2EN4eCuLa2WWtZ8=.48082189-314f-4c80-a503-c35b576fa5fd@github.com>
Message-ID: <K6LjJ-ruENGQBxoS_NXlHMgz0wBG8OMaB46FRG4_XFg=.0ae4a4fa-31a2-4e59-b7f7-cf7519f80490@github.com>

On Thu, 8 Jan 2026 06:54:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change to the jtreg failure handler that we use in the JDK? As noted in https://bugs.openjdk.org/browse/JDK-8374754 this change addresses the HTML rendering issues that are noticed in certain setups. The change here moves the inline javascript to a file of its own (generated as and when necessary).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   create the script and css files only if not already present

Thank you Erik for the review. I am waiting for a test run to complete and once that does, I'll go ahead and integrate this.

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

PR Comment: https://git.openjdk.org/jdk/pull/29106#issuecomment-3729560920

From jwaters at openjdk.org  Fri Jan  9 16:50:32 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 9 Jan 2026 16:50:32 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v7]
In-Reply-To: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
Message-ID: <VS97kixGpwheof1CDX5HvsiocjZydiv1Fjr17loiX-g=.d48e0a2e-96b4-4e8a-b77e-44e7baeab631@github.com>

> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
> 
> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
> - -flto is set to $(JOBS) instead of auto to better match what the user requested
> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch 'openjdk:master' into patch-16
 - Implement basic Link Time Optimization in LibCommon.gmk
 - Implement basic Link Time Optimization for executables in LauncherCommon.gmk
 - Revert LINK_TIME_OPTIMIZATION in ClientLibraries.gmk
 - Merge branch 'master' into patch-16
 - Merge branch 'master' into patch-16
 - Revert recent changes to ClientLibraries.gmk
 - Revert recent changes to CompileJvm.gmk
 - Revert recent changes to Flags.gmk
 - Revert recent changes to NativeCompilation.gmk
 - ... and 17 more: https://git.openjdk.org/jdk/compare/8737a8ca...47a6dc55

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

Changes: https://git.openjdk.org/jdk/pull/22464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=06
  Stats: 85 lines in 11 files changed: 35 ins; 46 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22464/head:pull/22464

PR: https://git.openjdk.org/jdk/pull/22464

From jwaters at openjdk.org  Fri Jan  9 17:10:01 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 9 Jan 2026 17:10:01 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <YcmtJTZnuF3cvk_hmiLJ9iRPuemScRy8-TYOMxwR1aU=.02b82828-147c-4ee4-a653-b811ec505f55@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <YcmtJTZnuF3cvk_hmiLJ9iRPuemScRy8-TYOMxwR1aU=.02b82828-147c-4ee4-a653-b811ec505f55@github.com>
Message-ID: <mciup4nU1nFVdSwgkNdd_Nbn0ymu7Wgxhe_-W9uE1gY=.f2722d6b-5202-4c83-9973-bbd05d0b4bea@github.com>

On Tue, 21 Oct 2025 13:37:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> FWIW, I'm prototyping a possible change in g1ParScanThreadState.cpp that might substantially reduce the amount of generated code there. It might not work out; I haven't done any performance testing yet, and it's really easy to introduce performance regressions when making changes to that code. But if it does work, that might help with the problems here.

Hi, I didn't ask initially because I didn't want to sound rude, but did this go anywhere? It would be a huge help if this change managed to curb the inlining in that file.

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3729828280

From ascarpino at openjdk.org  Fri Jan  9 20:15:12 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 9 Jan 2026 20:15:12 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
Message-ID: <AGdB79JAbaK2TB-mHV_mXuuRJ7Xr2PD8VgVu-tEhJDg=.35dffdc6-238a-4ffa-9328-dab91dd27a30@github.com>

On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   must have username; more comments

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3645433959

From ascarpino at openjdk.org  Fri Jan  9 20:15:15 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 9 Jan 2026 20:15:15 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <U6E7zbKhRYpSWOOyne6DBnZdpWanVKaBhL92x37En90=.91db86db-b6b7-40b4-b4bb-f711c96c3ee5@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
 <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com>
 <U6E7zbKhRYpSWOOyne6DBnZdpWanVKaBhL92x37En90=.91db86db-b6b7-40b4-b4bb-f711c96c3ee5@github.com>
Message-ID: <GfmoHmESGlNGFlNBF_XxakhrlPkkO4xOV_q3-jFcBg0=.b95d8e1e-35da-4918-9a6b-a5a73652d818@github.com>

On Wed, 7 Jan 2026 21:47:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:
>> 
>>> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
>>> 87: 
>>> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
>> 
>> Should the variables below be capitalized because they are `static final`?
>
> Per asked the same above. I'm not exactly sure if all of them should be capitalized. I'm willing to choose either.

I'm thinking the `static final` convention applies for all of them, but if someone says different because they are FFM related, I'm fine with not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2677493814

From kbarrett at openjdk.org  Fri Jan  9 22:38:52 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 Jan 2026 22:38:52 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <mciup4nU1nFVdSwgkNdd_Nbn0ymu7Wgxhe_-W9uE1gY=.f2722d6b-5202-4c83-9973-bbd05d0b4bea@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <YcmtJTZnuF3cvk_hmiLJ9iRPuemScRy8-TYOMxwR1aU=.02b82828-147c-4ee4-a653-b811ec505f55@github.com>
 <mciup4nU1nFVdSwgkNdd_Nbn0ymu7Wgxhe_-W9uE1gY=.f2722d6b-5202-4c83-9973-bbd05d0b4bea@github.com>
Message-ID: <TZ3qWzgHopJ0kcPVLtonaeV_4Q25MfumwteW0xHiY04=.88fc7fa8-1317-4064-9a0a-c69d0976a141@github.com>

On Fri, 9 Jan 2026 17:05:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Hi, I didn't ask initially because I didn't want to sound rude, but did this go anywhere? It would be a huge help if this change managed to curb the inlining in that file.

It's still in progress, and going slowly.  There's a lot of performance testing involved, and even small changes
can affect that.  It's one of the most performance-critical pieces of G1.

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3730804968

From jpai at openjdk.org  Sat Jan 10 02:19:58 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jan 2026 02:19:58 GMT
Subject: Integrated: 8374754: jtreg failure handler - replace inline javascript
 and inline event handlers with same origin javascript files
In-Reply-To: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
References: <yYbY0Gmlx9eBEquDB6SaD-DQF_2nmKP95-HX7M1T4wA=.77cf1c1f-e994-4e0b-a0d6-3480a72851f4@github.com>
Message-ID: <UYjlsUzXqWQEw3aDnT49rateIaj1V_-3-HfZvd2u7Lo=.c0d00ae1-6557-4a49-99cd-cc67911b8454@github.com>

On Thu, 8 Jan 2026 05:18:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the jtreg failure handler that we use in the JDK? As noted in https://bugs.openjdk.org/browse/JDK-8374754 this change addresses the HTML rendering issues that are noticed in certain setups. The change here moves the inline javascript to a file of its own (generated as and when necessary).

This pull request has now been integrated.

Changeset: 657d5f77
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/657d5f77f4985304995ee44fc2ae1643504de8df
Stats:     161 lines in 4 files changed: 98 ins; 39 del; 24 mod

8374754: jtreg failure handler - replace inline javascript and inline event handlers with same origin javascript files

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk/pull/29106

From jpai at openjdk.org  Sat Jan 10 05:21:19 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jan 2026 05:21:19 GMT
Subject: RFR: 8374181: failure_handler: The cores.html file is formatted
 incorrectly and so hides the core dump information
Message-ID: <JpNDU8i3bAQdsvQikJQDwf0uWHzbw_NFITmYA2o2Nv4=.90ebd954-0d9c-4728-9b18-c3ff4c2c000f@github.com>

Can I please get a review of this jtreg failure handler code change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374181?

The implementation in this failure handler generates a cores.html for each core file that was generated during the test run. The bug here is that instead of creating multiple "sections", one each for the core file, within an `<html>` element, it ends up creating multiple `<html>` elements one after another within the same HTML file. This causes the HTML rendering to go wrong.

The commit in this PR addresses that issue by creating one section, under the `<html>` element, for each core file.

I've verified that with this change, the cores.html is now correctly structured and rendered.

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

Commit messages:
 - 8374181: failure_handler: The cores.html file is formatted incorrectly and so hides the core dump information

Changes: https://git.openjdk.org/jdk/pull/29150/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29150&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374181
  Stats: 23 lines in 1 file changed: 12 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/29150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29150/head:pull/29150

PR: https://git.openjdk.org/jdk/pull/29150

From jwaters at openjdk.org  Sun Jan 11 13:09:08 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 11 Jan 2026 13:09:08 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <v79I3ptniGN8aMOkbkGZIEGLt5fXxIs1LJwegRHUvmw=.db15978c-3b3b-4bf1-980a-ef840d6f8ca2@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

I noticed this a bit too late, but I do recall gcc could be quite pedantic about whether the -g<Debug format flag> comes before or after the -g flag, as in -g -gdwarf-4 vs -gdwarf-4 -g. A little surprising you didn't run into it on your end. Hopefully this means the issue is no more within gcc.

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3734533432

From shade at openjdk.org  Sun Jan 11 20:41:14 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 11 Jan 2026 20:41:14 GMT
Subject: RFR: 8374521: Support fine-grained native debug levels [v3]
In-Reply-To: <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
References: <oN8qWYSDKeMV_IyCA33Z7dNrVJNQcVKHXWfo7S4esPU=.c426a988-d419-4070-9334-3b4f6c5fe314@github.com>
 <VcoGcG_NVWwJngWB_1Ju6Je_1UfF-8-a76ztnfvM-Lk=.3d100b46-3770-4b98-a76e-c682e042651c@github.com>
Message-ID: <MuiLgCGcdrKqGw_rJ4a1hrRot2BNZcP48chV20414yw=.6e05d490-2b01-41ff-9a6d-27ae5018b744@github.com>

On Tue, 6 Jan 2026 16:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look into debug info sizes again. And I remembered that GCC actually have debug-level support, which can select what kind of diagnostic data is in the debug info. See: https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html
>> 
>> Allowing users to configure the debug level allows two major deviations from the default level (2):
>>  level=1: significantly reduce the debug info size, but still allow backtrace reconstruction
>>  level=3: add even more debugging info, like macro expansion, into the debug data
>> 
>> This RFE upstreams the variant the patch that I have been using in builds.shipilev.net binaries: the fastdebug variants there are done with GCC level=1, greatly optimizing the debug binary sizes, while still maintaining the major benefit of debug binaries -- rich crash diagnostics.
>> 
>> I threw in this option into current GHA builds to conserve more disk space on runners and/or transfers. 
>> 
>> I am open for bikeshedding on the option name :)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to default, common the block, fail on incorrect debug level

> I noticed this a bit too late, but I do recall gcc could be quite pedantic about whether the -g comes before or after the -g flag, as in -g -gdwarf-4 vs -gdwarf-4 -g. A little surprising you didn't run into it on your end. Hopefully this means the issue is no more within gcc.

I did run into it, that is why there is a comment:


    # Debug info level should follow the debug format to be effective.
    CFLAGS_DEBUG_SYMBOLS="-gdwarf-4 ${DEBUG_INFO_LEVEL_FLAGS}"


GCC versions I tried on are working fine with this order, but not the other.

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

PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3735738468

From mbaesken at openjdk.org  Mon Jan 12 08:08:06 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jan 2026 08:08:06 GMT
Subject: RFR: 8374471: Check bin and lib folder of JDK image for unwanted
 files [v4]
In-Reply-To: <yWBYi3tN7-PtOYV6jMqxO3dPFJUeIXf-vxk-TUfN3BY=.eb837459-c3f4-4892-94a9-76f191555162@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
 <yWBYi3tN7-PtOYV6jMqxO3dPFJUeIXf-vxk-TUfN3BY=.eb837459-c3f4-4892-94a9-76f191555162@github.com>
Message-ID: <ILBamrlyiTdCIbn37dzDqS_MdzrQcbUfNl1POkDgxRg=.b98c9415-e3d0-44eb-bfc7-ad3c8e069b80@github.com>

On Thu, 8 Jan 2026 13:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect certain files in the bin and lib folders of the jdk image.
>> This should be checked by a test.
>> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add SAP copyright

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/29040#issuecomment-3737308821

From mbaesken at openjdk.org  Mon Jan 12 08:08:08 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jan 2026 08:08:08 GMT
Subject: Integrated: 8374471: Check bin and lib folder of JDK image for
 unwanted files
In-Reply-To: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
References: <DVTyLFZMHMzl1gIWrxSNB5oZZ1Fhd3fihYo-aJEGG6k=.ee1aa279-7eb2-4458-9638-dc4b8622364e@github.com>
Message-ID: <nQ01SID4SpH_G3Yvs2wwQ1anSXpnGoslSN1w0UC2tt4=.2ad9dc6f-9651-403f-b717-21553b90c734@github.com>

On Mon, 5 Jan 2026 15:51:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently expect certain files in the bin and lib folders of the jdk image.
> This should be checked by a test.
> For now we will probably not check for exact file lists; but certain files or file types (like exe / pdb / so etc.) will be allowed and others not.
> 
> See https://bugs.openjdk.org/browse/JDK-8373255 for examples of unwanted files.

This pull request has now been integrated.

Changeset: 133a023e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/133a023e8e1ec1c555265a92eb0fcb4965f0b162
Stats:     152 lines in 1 file changed: 152 ins; 0 del; 0 mod

8374471: Check bin and lib folder of JDK image for unwanted files

Reviewed-by: erikj, clanger

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

PR: https://git.openjdk.org/jdk/pull/29040

From shade at openjdk.org  Mon Jan 12 09:58:55 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Jan 2026 09:58:55 GMT
Subject: [jdk26] RFR: 8374507: GHA: Limit debug symbols generation to conserve
 disk space
Message-ID: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>

Now that [JDK-8373246](https://bugs.openjdk.org/browse/JDK-8373246) is in JDK 26, we need this fix to unbreak GHA in JDK 26.

Additional testing:
 - [ ] GHA

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

Commit messages:
 - Backport d063c9546b4a500f4c76fcd01442c2b7281f6d65

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

PR: https://git.openjdk.org/jdk/pull/29161

From clanger at openjdk.org  Mon Jan 12 10:55:28 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 12 Jan 2026 10:55:28 GMT
Subject: [jdk26] RFR: 8374507: GHA: Limit debug symbols generation to
 conserve disk space
In-Reply-To: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>
References: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>
Message-ID: <O4tZiLNcKjzbjb8BmBwwyMmP4X0ltz1mfzbOWic-pZo=.40fe9b6a-96ee-42bb-a5fe-104cae000960@github.com>

On Mon, 12 Jan 2026 09:50:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8373246](https://bugs.openjdk.org/browse/JDK-8373246) is in JDK 26, we need this fix to unbreak GHA in JDK 26.
> 
> Additional testing:
>  - [ ] GHA

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29161#pullrequestreview-3650167131

From mdoerr at openjdk.org  Mon Jan 12 11:41:05 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 12 Jan 2026 11:41:05 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
Message-ID: <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>

On Wed, 7 Jan 2026 14:05:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected.
>
>> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
> 
> Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here:
> 
> https://bugs.openjdk.org/browse/JDK-8336664
> 
> (apologies -- this link was already shared by @dmlloyd )

Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2681912656

From mbaesken at openjdk.org  Mon Jan 12 12:41:34 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jan 2026 12:41:34 GMT
Subject: RFR: 8374990: Check include folder of JDK image for unwanted files
Message-ID: <f_WN79g_GRfNAvve8elZ3X81VPxilihzT30IjuyBaTM=.bed48040-d7c1-488c-9918-255e5d597c77@github.com>

We currently expect header files in the include folder of the jdk image.
This should be checked by a test.
(recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))

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

Commit messages:
 - JDK-8374990

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

PR: https://git.openjdk.org/jdk/pull/29167

From mcimadamore at openjdk.org  Mon Jan 12 13:27:59 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jan 2026 13:27:59 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
Message-ID: <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>

On Mon, 12 Jan 2026 11:37:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
>> 
>> Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here:
>> 
>> https://bugs.openjdk.org/browse/JDK-8336664
>> 
>> (apologies -- this link was already shared by @dmlloyd )
>
> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?

At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2682268844

From mbaesken at openjdk.org  Mon Jan 12 13:47:29 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jan 2026 13:47:29 GMT
Subject: RFR: 8374990: Check include folder of JDK image for unwanted files
 [v2]
In-Reply-To: <f_WN79g_GRfNAvve8elZ3X81VPxilihzT30IjuyBaTM=.bed48040-d7c1-488c-9918-255e5d597c77@github.com>
References: <f_WN79g_GRfNAvve8elZ3X81VPxilihzT30IjuyBaTM=.bed48040-d7c1-488c-9918-255e5d597c77@github.com>
Message-ID: <RHoDPFvMe-wrlXNSYwxKk8tUMojAF8cwjCnq4M2I734=.7cef97fb-5cc3-4fdc-b784-f04b5fd639f4@github.com>

> We currently expect header files in the include folder of the jdk image.
> This should be checked by a test.
> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Add checking of jmods directory

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29167/files
  - new: https://git.openjdk.org/jdk/pull/29167/files/c7b8a193..b7f26145

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

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

PR: https://git.openjdk.org/jdk/pull/29167

From erikj at openjdk.org  Mon Jan 12 14:09:09 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 Jan 2026 14:09:09 GMT
Subject: RFR: 8374181: failure_handler: The cores.html file is formatted
 incorrectly and so hides the core dump information
In-Reply-To: <JpNDU8i3bAQdsvQikJQDwf0uWHzbw_NFITmYA2o2Nv4=.90ebd954-0d9c-4728-9b18-c3ff4c2c000f@github.com>
References: <JpNDU8i3bAQdsvQikJQDwf0uWHzbw_NFITmYA2o2Nv4=.90ebd954-0d9c-4728-9b18-c3ff4c2c000f@github.com>
Message-ID: <dvzMn29gzYWyopQz6oS_L5uJsxpAICbe8dvqS6BVaxE=.e58da120-2358-4f66-8b69-a8771a1313f6@github.com>

On Sat, 10 Jan 2026 05:14:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this jtreg failure handler code change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374181?
> 
> The implementation in this failure handler generates a cores.html for each core file that was generated during the test run. The bug here is that instead of creating multiple "sections", one each for the core file, within an `<html>` element, it ends up creating multiple `<html>` elements one after another within the same HTML file. This causes the HTML rendering to go wrong.
> 
> The commit in this PR addresses that issue by creating one section, under the `<html>` element, for each core file.
> 
> I've verified that with this change, the cores.html is now correctly structured and rendered.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29150#pullrequestreview-3650943246

From erikj at openjdk.org  Mon Jan 12 14:11:44 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 Jan 2026 14:11:44 GMT
Subject: [jdk26] RFR: 8374507: GHA: Limit debug symbols generation to
 conserve disk space
In-Reply-To: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>
References: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>
Message-ID: <mAHjXhNtfI7e-hKDhGMQFo6QETLvJflz-Vls809sLQM=.d0efd500-dafc-4200-b830-0b9c8d714ed9@github.com>

On Mon, 12 Jan 2026 09:50:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8373246](https://bugs.openjdk.org/browse/JDK-8373246) is in JDK 26, we need this fix to unbreak GHA in JDK 26.
> 
> Additional testing:
>  - [ ] GHA

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29161#pullrequestreview-3650948582

From erikj at openjdk.org  Mon Jan 12 14:12:16 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 Jan 2026 14:12:16 GMT
Subject: RFR: 8374990: Check include and jmods folder of JDK image for
 unwanted files [v2]
In-Reply-To: <RHoDPFvMe-wrlXNSYwxKk8tUMojAF8cwjCnq4M2I734=.7cef97fb-5cc3-4fdc-b784-f04b5fd639f4@github.com>
References: <f_WN79g_GRfNAvve8elZ3X81VPxilihzT30IjuyBaTM=.bed48040-d7c1-488c-9918-255e5d597c77@github.com>
 <RHoDPFvMe-wrlXNSYwxKk8tUMojAF8cwjCnq4M2I734=.7cef97fb-5cc3-4fdc-b784-f04b5fd639f4@github.com>
Message-ID: <qF3bfL6VuOsyykuZ5Se_b_lCoEIWAP9u3wWlMELo9qw=.04520c7c-6ad8-474a-a9cb-edf2aac9443b@github.com>

On Mon, 12 Jan 2026 13:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect header files in the include folder of the jdk image.
>> The jmods folder should just contain jmod files.
>> This should be checked by a test.
>> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add checking of jmods directory

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29167#pullrequestreview-3650954694

From shade at openjdk.org  Mon Jan 12 14:18:54 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Jan 2026 14:18:54 GMT
Subject: [jdk26] RFR: 8374507: GHA: Limit debug symbols generation to
 conserve disk space
In-Reply-To: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>
References: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>
Message-ID: <8117Cphx1NKLllLNbh7VvuUgX1c4UATQYzN58AmqD_w=.5269e516-bab3-483d-8a3b-ff9f176aa82c@github.com>

On Mon, 12 Jan 2026 09:50:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8373246](https://bugs.openjdk.org/browse/JDK-8373246) is in JDK 26, we need this fix to unbreak GHA in JDK 26.
> 
> Additional testing:
>  - [ ] GHA

Thanks for reviews! Testing is clean, I am integrating to unbreak JDK 26 GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/29161#issuecomment-3738768381

From shade at openjdk.org  Mon Jan 12 14:21:40 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Jan 2026 14:21:40 GMT
Subject: [jdk26] Integrated: 8374507: GHA: Limit debug symbols generation to
 conserve disk space
In-Reply-To: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>
References: <GQ61gzHgYdQCku5vCK-USVwNEImXt6KkGMPXHheoi20=.617cc260-cc43-4586-bf23-38e54c246981@github.com>
Message-ID: <Bfrz3qEan1oNQo5BS9sztzjVtiVPN5-YS4AoDdfIuEw=.7be50725-9e17-4987-b0cb-5b31f9176767@github.com>

On Mon, 12 Jan 2026 09:50:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8373246](https://bugs.openjdk.org/browse/JDK-8373246) is in JDK 26, we need this fix to unbreak GHA in JDK 26.
> 
> Additional testing:
>  - [ ] GHA

This pull request has now been integrated.

Changeset: f2ca96e8
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2ca96e8d102c409a181f989ea6d95206d992277
Stats:     5 lines in 5 files changed: 5 ins; 0 del; 0 mod

8374507: GHA: Limit debug symbols generation to conserve disk space

Reviewed-by: clanger, erikj
Backport-of: d063c9546b4a500f4c76fcd01442c2b7281f6d65

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

PR: https://git.openjdk.org/jdk/pull/29161

From tanksherman27 at gmail.com  Mon Jan 12 14:22:51 2026
From: tanksherman27 at gmail.com (Julian Waters)
Date: Mon, 12 Jan 2026 22:22:51 +0800
Subject: Documentation on SetupNativeCompilation incorrect
Message-ID: <CAP2b4GNrSfvaTy_2KT-DDALNHbbb4bzpXx63Qmg558sW=SHqMQ@mail.gmail.com>

Hi all,

The EXCLUDE_PATTERN parameter mentioned in the documentation of
SetupNativeCompilation appears to be incorrect, as the parameter name
actually seems to be EXCLUDE_PATTERNS with an S at the end. Can anyone
confirm whether the documentation is wrong before I send in a change
to fix it? Thank you!

best regards,
Julian

From jpai at openjdk.org  Mon Jan 12 15:49:00 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Jan 2026 15:49:00 GMT
Subject: RFR: 8374181: failure_handler: The cores.html file is formatted
 incorrectly and so hides the core dump information [v2]
In-Reply-To: <JpNDU8i3bAQdsvQikJQDwf0uWHzbw_NFITmYA2o2Nv4=.90ebd954-0d9c-4728-9b18-c3ff4c2c000f@github.com>
References: <JpNDU8i3bAQdsvQikJQDwf0uWHzbw_NFITmYA2o2Nv4=.90ebd954-0d9c-4728-9b18-c3ff4c2c000f@github.com>
Message-ID: <SWhl1_JgOU39FjuFnOAYz_1uDu3iaL3c0bkg3HLMOtg=.520119e1-92f1-4730-8d5b-64d9321929e5@github.com>

> Can I please get a review of this jtreg failure handler code change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374181?
> 
> The implementation in this failure handler generates a cores.html for each core file that was generated during the test run. The bug here is that instead of creating multiple "sections", one each for the core file, within an `<html>` element, it ends up creating multiple `<html>` elements one after another within the same HTML file. This causes the HTML rendering to go wrong.
> 
> The commit in this PR addresses that issue by creating one section, under the `<html>` element, for each core file.
> 
> I've verified that with this change, the cores.html is now correctly structured and rendered.

Jaikiran Pai 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 latest from master branch
 - 8374181: failure_handler: The cores.html file is formatted incorrectly and so hides the core dump information

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29150/files
  - new: https://git.openjdk.org/jdk/pull/29150/files/87ebe973..7fc8f6e8

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

  Stats: 967 lines in 32 files changed: 837 ins; 49 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29150/head:pull/29150

PR: https://git.openjdk.org/jdk/pull/29150

From jpai at openjdk.org  Tue Jan 13 01:32:30 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Jan 2026 01:32:30 GMT
Subject: RFR: 8374181: failure_handler: The cores.html file is formatted
 incorrectly and so hides the core dump information [v2]
In-Reply-To: <SWhl1_JgOU39FjuFnOAYz_1uDu3iaL3c0bkg3HLMOtg=.520119e1-92f1-4730-8d5b-64d9321929e5@github.com>
References: <JpNDU8i3bAQdsvQikJQDwf0uWHzbw_NFITmYA2o2Nv4=.90ebd954-0d9c-4728-9b18-c3ff4c2c000f@github.com>
 <SWhl1_JgOU39FjuFnOAYz_1uDu3iaL3c0bkg3HLMOtg=.520119e1-92f1-4730-8d5b-64d9321929e5@github.com>
Message-ID: <UeT7lHZQHpg5gA0lOrICvH8q_U7mrFYpKuIrxwa1YYY=.5e3200c3-b0c3-4e42-8beb-0cbadabacebf@github.com>

On Mon, 12 Jan 2026 15:49:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this jtreg failure handler code change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374181?
>> 
>> The implementation in this failure handler generates a cores.html for each core file that was generated during the test run. The bug here is that instead of creating multiple "sections", one each for the core file, within an `<html>` element, it ends up creating multiple `<html>` elements one after another within the same HTML file. This causes the HTML rendering to go wrong.
>> 
>> The commit in this PR addresses that issue by creating one section, under the `<html>` element, for each core file.
>> 
>> I've verified that with this change, the cores.html is now correctly structured and rendered.
>
> Jaikiran Pai 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 latest from master branch
>  - 8374181: failure_handler: The cores.html file is formatted incorrectly and so hides the core dump information

Thank you Erik for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/29150#issuecomment-3741351790

From jpai at openjdk.org  Tue Jan 13 01:32:31 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Jan 2026 01:32:31 GMT
Subject: Integrated: 8374181: failure_handler: The cores.html file is formatted
 incorrectly and so hides the core dump information
In-Reply-To: <JpNDU8i3bAQdsvQikJQDwf0uWHzbw_NFITmYA2o2Nv4=.90ebd954-0d9c-4728-9b18-c3ff4c2c000f@github.com>
References: <JpNDU8i3bAQdsvQikJQDwf0uWHzbw_NFITmYA2o2Nv4=.90ebd954-0d9c-4728-9b18-c3ff4c2c000f@github.com>
Message-ID: <CDgM6SLtFZHfMvkMtDRwN9qVIfS0_vcmzWZd6h7dBsc=.45325da2-de6f-49a7-b930-b03511042a60@github.com>

On Sat, 10 Jan 2026 05:14:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this jtreg failure handler code change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374181?
> 
> The implementation in this failure handler generates a cores.html for each core file that was generated during the test run. The bug here is that instead of creating multiple "sections", one each for the core file, within an `<html>` element, it ends up creating multiple `<html>` elements one after another within the same HTML file. This causes the HTML rendering to go wrong.
> 
> The commit in this PR addresses that issue by creating one section, under the `<html>` element, for each core file.
> 
> I've verified that with this change, the cores.html is now correctly structured and rendered.

This pull request has now been integrated.

Changeset: e89c1290
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e89c1290ca8b3e07bef12f4c0465c3e83389fef4
Stats:     23 lines in 1 file changed: 12 ins; 1 del; 10 mod

8374181: failure_handler: The cores.html file is formatted incorrectly and so hides the core dump information

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk/pull/29150

From mbaesken at openjdk.org  Tue Jan 13 13:52:01 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 13 Jan 2026 13:52:01 GMT
Subject: RFR: 8374990: Check include and jmods folder of JDK image for
 unwanted files [v2]
In-Reply-To: <RHoDPFvMe-wrlXNSYwxKk8tUMojAF8cwjCnq4M2I734=.7cef97fb-5cc3-4fdc-b784-f04b5fd639f4@github.com>
References: <f_WN79g_GRfNAvve8elZ3X81VPxilihzT30IjuyBaTM=.bed48040-d7c1-488c-9918-255e5d597c77@github.com>
 <RHoDPFvMe-wrlXNSYwxKk8tUMojAF8cwjCnq4M2I734=.7cef97fb-5cc3-4fdc-b784-f04b5fd639f4@github.com>
Message-ID: <AfygrylASBDvLtfEYty8fvbEa4iALxq2yuFdJmKQhKE=.27839494-7c81-4fb3-be43-7a33473de08d@github.com>

On Mon, 12 Jan 2026 13:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect header files in the include folder of the jdk image.
>> The jmods folder should just contain jmod files.
>> This should be checked by a test.
>> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add checking of jmods directory

Hi Erik, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/29167#issuecomment-3744432004

From mbaesken at openjdk.org  Tue Jan 13 13:54:14 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 13 Jan 2026 13:54:14 GMT
Subject: Integrated: 8374990: Check include and jmods folder of JDK image for
 unwanted files
In-Reply-To: <f_WN79g_GRfNAvve8elZ3X81VPxilihzT30IjuyBaTM=.bed48040-d7c1-488c-9918-255e5d597c77@github.com>
References: <f_WN79g_GRfNAvve8elZ3X81VPxilihzT30IjuyBaTM=.bed48040-d7c1-488c-9918-255e5d597c77@github.com>
Message-ID: <1FEsavjuTdTi2I3wrJ2rFssyrU_GaQL3LQCrIOg8Hcs=.d1cd6e98-5702-48ab-a7fd-62e1f0a48e46@github.com>

On Mon, 12 Jan 2026 12:34:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently expect header files in the include folder of the jdk image.
> The jmods folder should just contain jmod files.
> This should be checked by a test.
> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))

This pull request has now been integrated.

Changeset: 7330e1a9
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7330e1a996fd43d92430a73b818f33552bc6ae9c
Stats:     35 lines in 1 file changed: 33 ins; 0 del; 2 mod

8374990: Check include and jmods folder of JDK image for unwanted files

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk/pull/29167

From duke at openjdk.org  Tue Jan 13 15:54:23 2026
From: duke at openjdk.org (Ruben)
Date: Tue, 13 Jan 2026 15:54:23 GMT
Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods
 (int, float)
In-Reply-To: <KFgDNk__y8ot5_XNPCAiii1KMYHs_8T4sBkHSFUnhNY=.511f4a3b-3e59-4af6-bfac-c94bc10485ba@github.com>
References: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com>
 <KFgDNk__y8ot5_XNPCAiii1KMYHs_8T4sBkHSFUnhNY=.511f4a3b-3e59-4af6-bfac-c94bc10485ba@github.com>
Message-ID: <O7nt8YmesWRYMy8vLB2uUpPDofebgdwF4-8phGHaZ-s=.6a86634a-c702-41dd-8b1f-4e5e56e0443e@github.com>

On Tue, 9 Dec 2025 00:01:26 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> This patch adds an SVE implementation of primitive array sorting (Arrays.sort()) on AArch64 systems that support SVE. On non-SVE machines, we fall back to the existing Java implementation.
>> 
>> For smaller arrays (length <= 64), we use insertion sort; for larger arrays we use an SVE-vectorized quicksort partitioner followed by an odd-even transposition cleanup pass.
>> 
>> The SVE path is enabled by default for int type. For float type, it is available through the experimental flag :
>> 
>> `-XX:+UnlockExperimentalVMOptions -XX:+UseSVELibSimdSortForFP
>> `
>> Without this flag being enabled, the default Java implementation would be executed for floats (the flag is disabled by default).
>> 
>> Float is gated due to observed regressions on some small/medium sizes. On larger arrays, the SVE float path shows upto 1.47x speedup on Neoverse V2 and 2.12x on Neoverse V1.
>> 
>> Following are the performance numbers for **ArraysSort JMH benchmark** -
>> 
>> **Case A:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag disabled (which is the default).
>> **Case B:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag enabled (the int numbers will be the same but this now enables SVE vectorized sorting for floats).
>> **We would want the ratios to be >= 1 to be at par or better than the default Java implementation (master branch).**
>> 
>> On Neoverse V1:
>> 
>> 
>> Benchmark                       (size)   Mode    Cnt    A       B
>> ArraysSort.floatParallelSort    10       avgt    3      0.98    0.98
>> ArraysSort.floatParallelSort    25       avgt    3      1.01    0.83
>> ArraysSort.floatParallelSort    50       avgt    3      0.99    0.55
>> ArraysSort.floatParallelSort    75       avgt    3      0.99    0.66
>> ArraysSort.floatParallelSort    100      avgt    3      0.98    0.66
>> ArraysSort.floatParallelSort    1000     avgt    3      1.00    0.84
>> ArraysSort.floatParallelSort    10000    avgt    3      1.03    1.52
>> ArraysSort.floatParallelSort    100000   avgt    3      1.03    1.46
>> ArraysSort.floatParallelSort    1000000  avgt    3      0.98    1.81
>> ArraysSort.floatSort            10       avgt    3      1.00    0.98
>> ArraysSort.floatSort            25       avgt    3      1.00    0.81
>> ArraysSort.floatSort            50       avgt    3      0.99    0.56
>> ArraysSort.floatSort            75       avgt    3      0.99    0.65
>> ArraysSort.floatSort            100      avgt    3      0.98    0.70
>> ArraysSort.floatSort       ...
>
> Good work, Bhavana!
> 
> I reminds me of an effort I started a year ago to migrate native libraries to FFM.
> `vectormath` got integrated, but `libsimdsort` is still a draft:
>    https://github.com/iwanowww/jdk/tree/libsimdsort.1
> 
> Since you do profound refactorings in the libsimdsort library code, I suggest to introduce SVE variant on top of FFM from the beginning. Let me finalize the PR and post it for review. What do you think?

Hi @iwanowww,

Bhavana will be unavailable for some time, so I am coordinating the next steps and someone from our team will be taking over this PR. 

Thanks again for offering to finalize the libsimdsort FFM PR and post it for review. 

Do you have an estimate for when you expect to open it? We would like to plan the next update of the SVE Arrays.sort PR on top of it, so knowing an approximate timeline (and whether there is anything you would suggest we prepare in the meantime) would help.

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

PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3745085496

From duke at openjdk.org  Tue Jan 13 18:51:08 2026
From: duke at openjdk.org (duke)
Date: Tue, 13 Jan 2026 18:51:08 GMT
Subject: Withdrawn: 8371988: Typo in JTREG_TMIEOUT_FACTOR and TMIEOUT_FACTOR
 should be corrected
In-Reply-To: <2_H0qIMZKs5WbYGNzaNgZhoUlM3Dxf4g0bWLn5BS2Kc=.d99d784d-699d-4fc5-b55e-72145d5d11d2@github.com>
References: <2_H0qIMZKs5WbYGNzaNgZhoUlM3Dxf4g0bWLn5BS2Kc=.d99d784d-699d-4fc5-b55e-72145d5d11d2@github.com>
Message-ID: <0CXyVlcoIQeipaMdTtEGtOHWm5hlZJTqF07LsZRXcCI=.a922cccb-2935-42ac-a01c-3b29aeae24a7@github.com>

On Mon, 17 Nov 2025 13:34:09 GMT, Ramesh Bhagavatam Gangadhar <rgangadhar at openjdk.org> wrote:

> There are two typos in https://github.com/openjdk/jdk/blob/master/doc/testing.md
> 
> https://github.com/openjdk/jdk/blob/master/doc/testing.md?plain=1#L292
> 
> Wrong: JTREG_TMIEOUT_FACTOR
> Correct: JTREG_TIMEOUT_FACTOR
> 
> 
> Wrong: JTREG="TMIEOUT_FACTOR...
> Correct: JTREG="TIMEOUT_FACTOR...

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/28351

From weijun at openjdk.org  Tue Jan 13 21:17:13 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jan 2026 21:17:13 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>

> Rewrite the native calls with FFM.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  new naming style; use VarHandle to access fields

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/cfd794b8..bf91106e

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

  Stats: 36 lines in 1 file changed: 1 ins; 6 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/28931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931

PR: https://git.openjdk.org/jdk/pull/28931

From weijun at openjdk.org  Tue Jan 13 21:27:03 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jan 2026 21:27:03 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8]
In-Reply-To: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>
Message-ID: <CZoOTCNqfVxnOPmEudA6rdfwidfVlKnwiQnwE5M4MOA=.d50dbabe-c645-41f6-8dfd-6df593e0aa0b@github.com>

On Tue, 13 Jan 2026 21:17:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new naming style; use VarHandle to access fields

A new commit pushed after some offline discussion. Now using a new naming style with an uppercase PREFIX followed by the original C name. For example, a `MethodHandle` for `getgroups` becomes `MH_getgroups`. Also, switching to `VarHandle` for struct field retrieval.

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

PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3746638101

From weijun at openjdk.org  Tue Jan 13 21:27:04 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jan 2026 21:27:04 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
Message-ID: <HqlfAlkuLwwHJQGV_04tSQ4F8HG2ZyOvVUHXPAtaCeI=.cfe8933e-0cd8-49ec-9c94-382818738fed@github.com>

On Mon, 12 Jan 2026 11:37:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
>> 
>> Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here:
>> 
>> https://bugs.openjdk.org/browse/JDK-8336664
>> 
>> (apologies -- this link was already shared by @dmlloyd )
>
> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?

@TheRealMDoerr I haven't used your `calling_convention_requires_int_as_long` flag in my new commit. Can you investigate the approach in a different JBS issue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2688164522

From jwaters at openjdk.org  Wed Jan 14 06:14:55 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 14 Jan 2026 06:14:55 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
Message-ID: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>

--with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.

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

Commit messages:
 - Simplify native-debug-symbols-level in flags-cflags.m4

Changes: https://git.openjdk.org/jdk/pull/29214/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29214&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375241
  Stats: 20 lines in 1 file changed: 4 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/29214.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29214/head:pull/29214

PR: https://git.openjdk.org/jdk/pull/29214

From shade at openjdk.org  Wed Jan 14 10:41:41 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jan 2026 10:41:41 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
Message-ID: <086cpHvXIIJZtJFGcEO6KpFaheWcrafzBD2hScfVaJI=.c6cde713-ec3b-4824-bba0-8f9db09fb17e@github.com>

On Wed, 14 Jan 2026 03:01:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.

make/autoconf/flags-cflags.m4 line 107:

> 105: 
> 106:     # Debug info level should follow the debug format to be effective.
> 107:     CFLAGS_DEBUG_SYMBOLS="-g -gdwarf-4 -g${NATIVE_DEBUG_SYMBOLS_LEVEL}"

What is this supposed to fix/accomplish?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2689900810

From jwaters at openjdk.org  Wed Jan 14 11:45:13 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 14 Jan 2026 11:45:13 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <086cpHvXIIJZtJFGcEO6KpFaheWcrafzBD2hScfVaJI=.c6cde713-ec3b-4824-bba0-8f9db09fb17e@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <086cpHvXIIJZtJFGcEO6KpFaheWcrafzBD2hScfVaJI=.c6cde713-ec3b-4824-bba0-8f9db09fb17e@github.com>
Message-ID: <IztdWQuWj6ajUZtBJ285AxOySFTdVI3Uj1y7papdQg0=.a7897d1c-eb28-49b2-969e-127c94a6c10d@github.com>

On Wed, 14 Jan 2026 10:38:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.
>
> make/autoconf/flags-cflags.m4 line 107:
> 
>> 105: 
>> 106:     # Debug info level should follow the debug format to be effective.
>> 107:     CFLAGS_DEBUG_SYMBOLS="-g -gdwarf-4 -g${NATIVE_DEBUG_SYMBOLS_LEVEL}"
> 
> What is this supposed to fix/accomplish?

Do you mean the addition of the plain -g or the -g with NATIVE_DEBUG_SYMBOLS_LEVEL appended to it? The former I just added for correctness, it's not strictly needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2690103362

From shade at openjdk.org  Wed Jan 14 11:49:02 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jan 2026 11:49:02 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <IztdWQuWj6ajUZtBJ285AxOySFTdVI3Uj1y7papdQg0=.a7897d1c-eb28-49b2-969e-127c94a6c10d@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <086cpHvXIIJZtJFGcEO6KpFaheWcrafzBD2hScfVaJI=.c6cde713-ec3b-4824-bba0-8f9db09fb17e@github.com>
 <IztdWQuWj6ajUZtBJ285AxOySFTdVI3Uj1y7papdQg0=.a7897d1c-eb28-49b2-969e-127c94a6c10d@github.com>
Message-ID: <rbMtVgtafKLhZwj8EaplcEddl8fH2b0ImjbZdwiUBKo=.27f7f944-df67-47dd-a744-92fbac7ae374@github.com>

On Wed, 14 Jan 2026 11:41:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 107:
>> 
>>> 105: 
>>> 106:     # Debug info level should follow the debug format to be effective.
>>> 107:     CFLAGS_DEBUG_SYMBOLS="-g -gdwarf-4 -g${NATIVE_DEBUG_SYMBOLS_LEVEL}"
>> 
>> What is this supposed to fix/accomplish?
>
> Do you mean the addition of the plain -g or the -g with NATIVE_DEBUG_SYMBOLS_LEVEL appended to it? The former I just added for correctness, it's not strictly needed.

Yes, I am curious why do we need a plain `-g`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2690122775

From jwaters at openjdk.org  Wed Jan 14 12:03:27 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 14 Jan 2026 12:03:27 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <rbMtVgtafKLhZwj8EaplcEddl8fH2b0ImjbZdwiUBKo=.27f7f944-df67-47dd-a744-92fbac7ae374@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <086cpHvXIIJZtJFGcEO6KpFaheWcrafzBD2hScfVaJI=.c6cde713-ec3b-4824-bba0-8f9db09fb17e@github.com>
 <IztdWQuWj6ajUZtBJ285AxOySFTdVI3Uj1y7papdQg0=.a7897d1c-eb28-49b2-969e-127c94a6c10d@github.com>
 <rbMtVgtafKLhZwj8EaplcEddl8fH2b0ImjbZdwiUBKo=.27f7f944-df67-47dd-a744-92fbac7ae374@github.com>
Message-ID: <UE4kSdDYA10ks-ACpyoB_ydFHXhXhLI7iy-CqzL8nt8=.c31881b5-3b4f-41e6-9fe3-e5efe5225c32@github.com>

On Wed, 14 Jan 2026 11:47:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Do you mean the addition of the plain -g or the -g with NATIVE_DEBUG_SYMBOLS_LEVEL appended to it? The former I just added for correctness, it's not strictly needed.
>
> Yes, I am curious why do we need a plain `-g`.

It's more just paranoia and for correctness really. I can remove it if desired.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2690159112

From shade at openjdk.org  Wed Jan 14 12:33:58 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jan 2026 12:33:58 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <UE4kSdDYA10ks-ACpyoB_ydFHXhXhLI7iy-CqzL8nt8=.c31881b5-3b4f-41e6-9fe3-e5efe5225c32@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <086cpHvXIIJZtJFGcEO6KpFaheWcrafzBD2hScfVaJI=.c6cde713-ec3b-4824-bba0-8f9db09fb17e@github.com>
 <IztdWQuWj6ajUZtBJ285AxOySFTdVI3Uj1y7papdQg0=.a7897d1c-eb28-49b2-969e-127c94a6c10d@github.com>
 <rbMtVgtafKLhZwj8EaplcEddl8fH2b0ImjbZdwiUBKo=.27f7f944-df67-47dd-a744-92fbac7ae374@github.com>
 <UE4kSdDYA10ks-ACpyoB_ydFHXhXhLI7iy-CqzL8nt8=.c31881b5-3b4f-41e6-9fe3-e5efe5225c32@github.com>
Message-ID: <25rebdEhVGefgZHatO3pktpEeHIgHjA3mceuJ2mHxu4=.3dfbe93d-69ee-46d8-9409-c927b68646e6@github.com>

On Wed, 14 Jan 2026 12:00:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Yes, I am curious why do we need a plain `-g`.
>
> It's more just paranoia and for correctness really. I can remove it if desired.

I mean, I am good with paranoia argument, I just need to understand what are the paranoid grounds for this paranoia :) What are you thinking this solves?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2690249089

From erikj at openjdk.org  Wed Jan 14 14:28:46 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 14 Jan 2026 14:28:46 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
Message-ID: <_Gx7uroawQyem04nDqRcN36Sh4aFRqSv2BSVgiktdR0=.ba345f45-f238-4f74-893e-6698897ed1d5@github.com>

On Wed, 14 Jan 2026 03:01:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.

The rewrite of the macro call looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/29214#pullrequestreview-3661008001

From erikj at openjdk.org  Wed Jan 14 14:28:48 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 14 Jan 2026 14:28:48 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <25rebdEhVGefgZHatO3pktpEeHIgHjA3mceuJ2mHxu4=.3dfbe93d-69ee-46d8-9409-c927b68646e6@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <086cpHvXIIJZtJFGcEO6KpFaheWcrafzBD2hScfVaJI=.c6cde713-ec3b-4824-bba0-8f9db09fb17e@github.com>
 <IztdWQuWj6ajUZtBJ285AxOySFTdVI3Uj1y7papdQg0=.a7897d1c-eb28-49b2-969e-127c94a6c10d@github.com>
 <rbMtVgtafKLhZwj8EaplcEddl8fH2b0ImjbZdwiUBKo=.27f7f944-df67-47dd-a744-92fbac7ae374@github.com>
 <UE4kSdDYA10ks-ACpyoB_ydFHXhXhLI7iy-CqzL8nt8=.c31881b5-3b4f-41e6-9fe3-e5efe5225c32@github.com>
 <25rebdEhVGefgZHatO3pktpEeHIgHjA3mceuJ2mHxu4=.3dfbe93d-69ee-46d8-9409-c927b68646e6@github.com>
Message-ID: <YeOLg0ngzw5aLFHhmwvIO6it1yf9ckstAkOPjW1JX5o=.475835ac-9676-42cb-96bb-3e98290b268c@github.com>

On Wed, 14 Jan 2026 12:30:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> It's more just paranoia and for correctness really. I can remove it if desired.
>
> I mean, I am good with paranoia argument, I just need to understand what are the paranoid grounds for this paranoia :) What are you thinking this solves?

Seems unnecessary to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2690656049

From jwaters at openjdk.org  Wed Jan 14 14:35:18 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 14 Jan 2026 14:35:18 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <25rebdEhVGefgZHatO3pktpEeHIgHjA3mceuJ2mHxu4=.3dfbe93d-69ee-46d8-9409-c927b68646e6@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <086cpHvXIIJZtJFGcEO6KpFaheWcrafzBD2hScfVaJI=.c6cde713-ec3b-4824-bba0-8f9db09fb17e@github.com>
 <IztdWQuWj6ajUZtBJ285AxOySFTdVI3Uj1y7papdQg0=.a7897d1c-eb28-49b2-969e-127c94a6c10d@github.com>
 <rbMtVgtafKLhZwj8EaplcEddl8fH2b0ImjbZdwiUBKo=.27f7f944-df67-47dd-a744-92fbac7ae374@github.com>
 <UE4kSdDYA10ks-ACpyoB_ydFHXhXhLI7iy-CqzL8nt8=.c31881b5-3b4f-41e6-9fe3-e5efe5225c32@github.com>
 <25rebdEhVGefgZHatO3pktpEeHIgHjA3mceuJ2mHxu4=.3dfbe93d-69ee-46d8-9409-c927b68646e6@github.com>
Message-ID: <ktwI_Th82CaA3YGXArPb7oY0FB0oYpbEQpc_8902PR4=.6e0d1d4f-ec2e-4550-bff3-3a3a6d7f9233@github.com>

On Wed, 14 Jan 2026 12:30:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> It's more just paranoia and for correctness really. I can remove it if desired.
>
> I mean, I am good with paranoia argument, I just need to understand what are the paranoid grounds for this paranoia :) What are you thinking this solves?

@shipilev I recall that gcc at least can get confused by what kind of debug information it's supposed to create if the flags aren't specified in exactly that order (The joy of being aware of super obscure gcc bugs that can't simply be googled), but yeah you're right it's probably unnecessary. I'll remove it in the morning tomorrow since everyone agrees on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2690685774

From mdoerr at openjdk.org  Thu Jan 15 09:34:47 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 15 Jan 2026 09:34:47 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <HqlfAlkuLwwHJQGV_04tSQ4F8HG2ZyOvVUHXPAtaCeI=.cfe8933e-0cd8-49ec-9c94-382818738fed@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <HqlfAlkuLwwHJQGV_04tSQ4F8HG2ZyOvVUHXPAtaCeI=.cfe8933e-0cd8-49ec-9c94-382818738fed@github.com>
Message-ID: <dtkJ9M8YMpq4xq8BCq7Fr1bc1ETY7NX-at0rFBQiU9o=.089ab056-830b-4529-8388-9be1486bf5a3@github.com>

On Tue, 13 Jan 2026 21:21:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?
>
> @TheRealMDoerr I haven't used your `calling_convention_requires_int_as_long` flag in my new commit. Can you investigate the approach in a different JBS issue?

I would prefer to have no undefined behavior from the beginning. However, if you don't feed comfortable with it, we could file a follow-up issue. I don't think there's much to investigate because there's no alternative before we get [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2693634221

From aph at openjdk.org  Thu Jan 15 12:48:01 2026
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 Jan 2026 12:48:01 GMT
Subject: RFR: 8372701: Randomized profile counters [v6]
In-Reply-To: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
Message-ID: <GYbxe-DrI0oOr9wb0u6JETvTeGuDVP2AS1BanLSgDRk=.29d29126-818e-4459-b374-a70b0dfd0a96@github.com>

> Please use [this link](https://github.com/openjdk/jdk/pull/28541/files?w=1) to view the files changed.
> 
> Profile counters scale very badly.
> 
> The overhead for profiled code isn't too bad with one thread, but as the thread count increases, things go wrong very quickly.
> 
> For example, here's a benchmark from the OpenJDK test suite, run at TieredLevel 3 with one thread, then three threads:
> 
> 
> Benchmark (randomized) Mode Cnt Score Error Units
> InterfaceCalls.test2ndInt5Types false avgt 4 27.468 ? 2.631 ns/op
> InterfaceCalls.test2ndInt5Types false avgt 4 240.010 ? 6.329 ns/op
> 
> 
> This slowdown is caused by high memory contention on the profile counters. Not only is this slow, but it can also lose profile counts.
> 
> This patch is for C1 only. It'd be easy to randomize C1 counters as well in another PR, if anyone thinks it's worth doing.
> 
> One other thing to note is that randomized profile counters degrade very badly with small decimation ratios. For example, using a ratio of 2 with `-XX:ProfileCaptureRatio=2` with a single thread results in
> 
> 
> Benchmark                        (randomized)  Mode  Cnt   Score   Error  Units
> InterfaceCalls.test2ndInt5Types         false  avgt    4  80.147 ? 9.991  ns/op
> 
> 
> The problem is that the branch prediction rate drops away very badly, leading to many mispredictions. It only really makes sense to use higher decimation ratios, e.g. 64.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Merge from 3f5b827d36a6615ddb99a1d1daff8bc954c52438 (origin/8372701-exp, 8372701-exp)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28541/files
  - new: https://git.openjdk.org/jdk/pull/28541/files/96db42e2..7d124fd2

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

  Stats: 558 lines in 21 files changed: 433 ins; 45 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/28541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28541/head:pull/28541

PR: https://git.openjdk.org/jdk/pull/28541

From aph at openjdk.org  Thu Jan 15 16:39:51 2026
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 Jan 2026 16:39:51 GMT
Subject: RFR: 8372701: Randomized profile counters [v7]
In-Reply-To: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
Message-ID: <kms9In15qoXMrcr24YxoXO-H8FG3mqEdeeD_hhVxmi0=.4c32346c-8041-4482-b51c-3749214a7ff1@github.com>

> Please use [this link](https://github.com/openjdk/jdk/pull/28541/files?w=1) to view the files changed.
> 
> Profile counters scale very badly.
> 
> The overhead for profiled code isn't too bad with one thread, but as the thread count increases, things go wrong very quickly.
> 
> For example, here's a benchmark from the OpenJDK test suite, run at TieredLevel 3 with one thread, then three threads:
> 
> 
> Benchmark (randomized) Mode Cnt Score Error Units
> InterfaceCalls.test2ndInt5Types false avgt 4 27.468 ? 2.631 ns/op
> InterfaceCalls.test2ndInt5Types false avgt 4 240.010 ? 6.329 ns/op
> 
> 
> This slowdown is caused by high memory contention on the profile counters. Not only is this slow, but it can also lose profile counts.
> 
> This patch is for C1 only. It'd be easy to randomize C1 counters as well in another PR, if anyone thinks it's worth doing.
> 
> One other thing to note is that randomized profile counters degrade very badly with small decimation ratios. For example, using a ratio of 2 with `-XX:ProfileCaptureRatio=2` with a single thread results in
> 
> 
> Benchmark                        (randomized)  Mode  Cnt   Score   Error  Units
> InterfaceCalls.test2ndInt5Types         false  avgt    4  80.147 ? 9.991  ns/op
> 
> 
> The problem is that the branch prediction rate drops away very badly, leading to many mispredictions. It only really makes sense to use higher decimation ratios, e.g. 64.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28541/files
  - new: https://git.openjdk.org/jdk/pull/28541/files/7d124fd2..a1ed4b80

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

  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28541/head:pull/28541

PR: https://git.openjdk.org/jdk/pull/28541

From weijun at openjdk.org  Thu Jan 15 18:11:14 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Jan 2026 18:11:14 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
Message-ID: <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>

On Mon, 12 Jan 2026 13:25:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?
>
> At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround.

I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to  include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2695433254

From mdoerr at openjdk.org  Thu Jan 15 23:11:02 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 15 Jan 2026 23:11:02 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
 <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>
Message-ID: <un--qP6HOPN7VyxKxZLIUwJbVHgZbqZ_dwQYYbdF004=.4dee79fb-20f2-47ef-8965-a1e01e0e30c5@github.com>

On Thu, 15 Jan 2026 18:06:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround.
>
> I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to  include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633?

For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs`  for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2696282888

From mbaesken at openjdk.org  Fri Jan 16 09:22:07 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Jan 2026 09:22:07 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
Message-ID: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>

We currently expect certain files in the legal folder of the jdk image.
This should be checked by a test.
(recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))

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

Commit messages:
 - JDK-8375458

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

PR: https://git.openjdk.org/jdk/pull/29272

From mbaesken at openjdk.org  Fri Jan 16 14:23:51 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Jan 2026 14:23:51 GMT
Subject: RFR: 8369187: Add wrapper for <new> that forbids use of global
 allocation and deallocation functions [v3]
In-Reply-To: <a-kf2IeIsiCHIO9_BZT9jNCUBC_Cagx-ZUmoLBw853A=.d3afb17c-c75b-44c6-834c-15fce398c25b@github.com>
References: <tXVQcNiGES9E_0NmYnKmM1xNVapTCJYDVegSK1a4arQ=.d4d2d244-2abd-47cf-952c-a052cf02539e@github.com>
 <a-kf2IeIsiCHIO9_BZT9jNCUBC_Cagx-ZUmoLBw853A=.d3afb17c-c75b-44c6-834c-15fce398c25b@github.com>
Message-ID: <x03GkEdsoWPFw-zhSuJupO2FKBj1zabPEaBFvTlvhr8=.6e1ebafa-5040-41c4-9f90-fcd01d1ffccf@github.com>

On Sun, 16 Nov 2025 01:10:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 8369187: Add wrapper for <new> that forbids use of global allocation and deallocation functions
>> 
>> Please review this change that adds `cppstdlib/new.hpp` as a wrapper for
>> including `<new>`. All existing inclusions of `<new>` are changed to include
>> the new wrapper.
>> 
>> In additional to including `<new>`, this wrapper also provides deprecation
>> declarations to prevent the use of some facilities by HotSpot code.
>> 
>> However, those deprecations need to be conditionalized to not apply to gtests,
>> so this change also adds a macro definition provided by the build system for
>> use in detecting that a header is being included by a gtest.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into wrap-stdlib-new
>  - poison implicit alloc/dealloc in globalDefinitions
>  - Merge branch 'master' into wrap-stdlib-new
>  - further conditionalize deprecation of hardare interference sizes
>  - add wrapper for <new>

When experimenting with the link time gc  OpenJDK configure option , I notice that the 2  symbols hardware_destructive_interference_size  /  fgrep hardware_constructive_interference_size  are eliminated more then 2000 (!) times from the objects of libjvm  (I enabled verbose priting to see what is eliminated)

fgrep hardware_destructive_interference_size  build.log | wc -l
2681
fgrep hardware_constructive_interference_size  build.log | wc -l
2681


With default settings (no linktime gc)  I see the symbol now in HS (fortunately only 2 times , not 2000+)


strings /linuxx86_64/jdk-opt/images/jdk/lib/server/libjvm.so | grep hardware_constructive_interference_size
_ZSt39hardware_constructive_interference_size
_ZSt39hardware_constructive_interference_size


Was this intended to got into libjvm.so ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28250#issuecomment-3760241677

From erikj at openjdk.org  Fri Jan 16 15:48:53 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 16 Jan 2026 15:48:53 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
In-Reply-To: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
Message-ID: <sX0LP4FDXxWUw5_4drz7bX1pYEANVMGMfW1_u5cT49k=.c884129b-248b-4f0e-b3bb-5529d7d415e9@github.com>

On Fri, 16 Jan 2026 09:13:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently expect certain files in the legal folder of the jdk image.
> This should be checked by a test.
> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))

test/jdk/build/CheckFiles.java line 164:

> 162:         requiredFilesInLegalSubdirs.add("ADDITIONAL_LICENSE_INFO");
> 163:         requiredFilesInLegalSubdirs.add("ASSEMBLY_EXCEPTION");
> 164:         requiredFilesInLegalSubdirs.add("LICENSE");

This set of files is expected for OpenJDK builds, but different vendors may be building the JDK under different license agreements and consequently, this set of files will differ. As an example, OracleJDK has the files `LICENSE` and `COPYRIGHT`.

I think we can check for the file `LICENSE`. If we are to check for the rest of the upper case files, it needs to be conditional on the LICENSE being GPL.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29272#discussion_r2699023857

From vlivanov at openjdk.org  Fri Jan 16 23:24:20 2026
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 16 Jan 2026 23:24:20 GMT
Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods
 (int, float)
In-Reply-To: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com>
References: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com>
Message-ID: <HrW759k3wGdLnMEzK3lp5mS8W-37epC5KdcKUelul7Q=.342e5ebc-80e0-438b-81d2-57fc4559285e@github.com>

On Fri, 5 Dec 2025 09:44:16 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds an SVE implementation of primitive array sorting (Arrays.sort()) on AArch64 systems that support SVE. On non-SVE machines, we fall back to the existing Java implementation.
> 
> For smaller arrays (length <= 64), we use insertion sort; for larger arrays we use an SVE-vectorized quicksort partitioner followed by an odd-even transposition cleanup pass.
> 
> The SVE path is enabled by default for int type. For float type, it is available through the experimental flag :
> 
> `-XX:+UnlockExperimentalVMOptions -XX:+UseSVELibSimdSortForFP
> `
> Without this flag being enabled, the default Java implementation would be executed for floats (the flag is disabled by default).
> 
> Float is gated due to observed regressions on some small/medium sizes. On larger arrays, the SVE float path shows upto 1.47x speedup on Neoverse V2 and 2.12x on Neoverse V1.
> 
> Following are the performance numbers for **ArraysSort JMH benchmark** -
> 
> **Case A:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag disabled (which is the default).
> **Case B:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag enabled (the int numbers will be the same but this now enables SVE vectorized sorting for floats).
> **We would want the ratios to be >= 1 to be at par or better than the default Java implementation (master branch).**
> 
> On Neoverse V1:
> 
> 
> Benchmark                       (size)   Mode    Cnt    A       B
> ArraysSort.floatParallelSort    10       avgt    3      0.98    0.98
> ArraysSort.floatParallelSort    25       avgt    3      1.01    0.83
> ArraysSort.floatParallelSort    50       avgt    3      0.99    0.55
> ArraysSort.floatParallelSort    75       avgt    3      0.99    0.66
> ArraysSort.floatParallelSort    100      avgt    3      0.98    0.66
> ArraysSort.floatParallelSort    1000     avgt    3      1.00    0.84
> ArraysSort.floatParallelSort    10000    avgt    3      1.03    1.52
> ArraysSort.floatParallelSort    100000   avgt    3      1.03    1.46
> ArraysSort.floatParallelSort    1000000  avgt    3      0.98    1.81
> ArraysSort.floatSort            10       avgt    3      1.00    0.98
> ArraysSort.floatSort            25       avgt    3      1.00    0.81
> ArraysSort.floatSort            50       avgt    3      0.99    0.56
> ArraysSort.floatSort            75       avgt    3      0.99    0.65
> ArraysSort.floatSort            100      avgt    3      0.98    0.70
> ArraysSort.floatSort            1000     avgt    3      0.99    0.84
> ArraysSort.floatSort            ...

Currently, I'm in process of conducting performance testing. I plan to finish it in a week and post for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3762195958

From jwaters at openjdk.org  Mon Jan 19 07:04:36 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Jan 2026 07:04:36 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v2]
In-Reply-To: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
Message-ID: <boqdeVbdoUgRWerKe1Dy9sQssJNwlVBTLF3iDsM6PLo=.4e96fe41-afa4-4e15-b0c1-d11ff2b2cacc@github.com>

> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Remove -g and don't pass the flag at all if option is not given flags-cflags.m4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29214/files
  - new: https://git.openjdk.org/jdk/pull/29214/files/bb986cf2..d6a1e78d

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

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

PR: https://git.openjdk.org/jdk/pull/29214

From jwaters at openjdk.org  Mon Jan 19 07:04:37 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Jan 2026 07:04:37 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
Message-ID: <GgaqPjZJWQMneVogncix90XYHlc0DeMR_bhmdXnJPAM=.f40168c2-4ebf-4cf5-9ba9-69b26681a8a0@github.com>

On Wed, 14 Jan 2026 03:01:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.

I'm testing to see if I can omit the -g2 entirely from the command line if the option is not passed. Stand by...

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

PR Comment: https://git.openjdk.org/jdk/pull/29214#issuecomment-3766757999

From shade at openjdk.org  Mon Jan 19 07:54:26 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Jan 2026 07:54:26 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v2]
In-Reply-To: <boqdeVbdoUgRWerKe1Dy9sQssJNwlVBTLF3iDsM6PLo=.4e96fe41-afa4-4e15-b0c1-d11ff2b2cacc@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <boqdeVbdoUgRWerKe1Dy9sQssJNwlVBTLF3iDsM6PLo=.4e96fe41-afa4-4e15-b0c1-d11ff2b2cacc@github.com>
Message-ID: <S5686g_gx3BB5qZVkctGUcoGwQ2QuIfv23EBI14gyBM=.d0f9be65-6b0b-4915-9f9d-63605b08c9b2@github.com>

On Mon, 19 Jan 2026 07:04:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove -g and don't pass the flag at all if option is not given flags-cflags.m4

make/autoconf/flags-cflags.m4 line 85:

> 83:     ],
> 84:     IF_NOT_GIVEN: [
> 85:       NATIVE_DEBUG_SYMBOLS_LEVEL=""

I would have thought this needs to be `-g`, so we pass `-g` when `--native-debug-symbols-level` is not specified?

make/autoconf/flags-cflags.m4 line 113:

> 111: 
> 112:     # Debug info level should follow the debug format to be effective.
> 113:     CFLAGS_DEBUG_SYMBOLS="-gdwarf-4 ${NATIVE_DEBUG_SYMBOLS_LEVEL}"

Yeah, from this definition, it is not a "level", it is "flags". So name it e.g. `NATIVE_DEBUG_SYMBOLS_FLAGS` or some such?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2703626427
PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2703629603

From jwaters at openjdk.org  Mon Jan 19 08:10:56 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Jan 2026 08:10:56 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v2]
In-Reply-To: <S5686g_gx3BB5qZVkctGUcoGwQ2QuIfv23EBI14gyBM=.d0f9be65-6b0b-4915-9f9d-63605b08c9b2@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <boqdeVbdoUgRWerKe1Dy9sQssJNwlVBTLF3iDsM6PLo=.4e96fe41-afa4-4e15-b0c1-d11ff2b2cacc@github.com>
 <S5686g_gx3BB5qZVkctGUcoGwQ2QuIfv23EBI14gyBM=.d0f9be65-6b0b-4915-9f9d-63605b08c9b2@github.com>
Message-ID: <TLJdGcnXRiIdJ4cvkKOmObzCTEUks7q0JMyrqUqF_80=.3ab761c1-e50f-4886-b8f4-27e832dd3c04@github.com>

On Mon, 19 Jan 2026 07:51:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove -g and don't pass the flag at all if option is not given flags-cflags.m4
>
> make/autoconf/flags-cflags.m4 line 85:
> 
>> 83:     ],
>> 84:     IF_NOT_GIVEN: [
>> 85:       NATIVE_DEBUG_SYMBOLS_LEVEL=""
> 
> I would have thought this needs to be `-g`, so we pass `-g` when `--native-debug-symbols-level` is not specified?

Good catch, I forgot about that, will revert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2703668932

From jwaters at openjdk.org  Mon Jan 19 08:10:56 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Jan 2026 08:10:56 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v2]
In-Reply-To: <TLJdGcnXRiIdJ4cvkKOmObzCTEUks7q0JMyrqUqF_80=.3ab761c1-e50f-4886-b8f4-27e832dd3c04@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <boqdeVbdoUgRWerKe1Dy9sQssJNwlVBTLF3iDsM6PLo=.4e96fe41-afa4-4e15-b0c1-d11ff2b2cacc@github.com>
 <S5686g_gx3BB5qZVkctGUcoGwQ2QuIfv23EBI14gyBM=.d0f9be65-6b0b-4915-9f9d-63605b08c9b2@github.com>
 <TLJdGcnXRiIdJ4cvkKOmObzCTEUks7q0JMyrqUqF_80=.3ab761c1-e50f-4886-b8f4-27e832dd3c04@github.com>
Message-ID: <FR6T01Au4eU-SQBX3H1vTKqaru2R6ZBt2ftr26uRciw=.fb5b3846-fe0a-49c1-b2ec-1018e932cc74@github.com>

On Mon, 19 Jan 2026 08:06:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 85:
>> 
>>> 83:     ],
>>> 84:     IF_NOT_GIVEN: [
>>> 85:       NATIVE_DEBUG_SYMBOLS_LEVEL=""
>> 
>> I would have thought this needs to be `-g`, so we pass `-g` when `--native-debug-symbols-level` is not specified?
>
> Good catch, I forgot about that, will revert.

Actually, on second thought, reverting the last commit will pass -g2 when the flag is not passed to configure, are you fine with that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2703670840

From shade at openjdk.org  Mon Jan 19 08:48:41 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Jan 2026 08:48:41 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v2]
In-Reply-To: <FR6T01Au4eU-SQBX3H1vTKqaru2R6ZBt2ftr26uRciw=.fb5b3846-fe0a-49c1-b2ec-1018e932cc74@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <boqdeVbdoUgRWerKe1Dy9sQssJNwlVBTLF3iDsM6PLo=.4e96fe41-afa4-4e15-b0c1-d11ff2b2cacc@github.com>
 <S5686g_gx3BB5qZVkctGUcoGwQ2QuIfv23EBI14gyBM=.d0f9be65-6b0b-4915-9f9d-63605b08c9b2@github.com>
 <TLJdGcnXRiIdJ4cvkKOmObzCTEUks7q0JMyrqUqF_80=.3ab761c1-e50f-4886-b8f4-27e832dd3c04@github.com>
 <FR6T01Au4eU-SQBX3H1vTKqaru2R6ZBt2ftr26uRciw=.fb5b3846-fe0a-49c1-b2ec-1018e932cc74@github.com>
Message-ID: <1ze3I69zjVzs6Q3MVm8JbypOTLlneT2eZscztT6ayi8=.aa4b37b7-6340-4b7e-9b8f-c11c745f99ae@github.com>

On Mon, 19 Jan 2026 08:06:52 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Good catch, I forgot about that, will revert.
>
> Actually, on second thought, reverting the last commit will pass -g2 when the flag is not passed to configure, are you fine with that?

Not really, I would like to pass `-g` if level is not overridden. I.e. to dodge bugs if toolchain does not support `-g2` for some weird reason, or `2` is not the actual default for some other weird reason. In the original change, that was the intent: either pass `-g` or `-g<num>` if user provided us with the num.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2703785783

From jwaters at openjdk.org  Mon Jan 19 10:22:34 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Jan 2026 10:22:34 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v2]
In-Reply-To: <1ze3I69zjVzs6Q3MVm8JbypOTLlneT2eZscztT6ayi8=.aa4b37b7-6340-4b7e-9b8f-c11c745f99ae@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <boqdeVbdoUgRWerKe1Dy9sQssJNwlVBTLF3iDsM6PLo=.4e96fe41-afa4-4e15-b0c1-d11ff2b2cacc@github.com>
 <S5686g_gx3BB5qZVkctGUcoGwQ2QuIfv23EBI14gyBM=.d0f9be65-6b0b-4915-9f9d-63605b08c9b2@github.com>
 <TLJdGcnXRiIdJ4cvkKOmObzCTEUks7q0JMyrqUqF_80=.3ab761c1-e50f-4886-b8f4-27e832dd3c04@github.com>
 <FR6T01Au4eU-SQBX3H1vTKqaru2R6ZBt2ftr26uRciw=.fb5b3846-fe0a-49c1-b2ec-1018e932cc74@github.com>
 <1ze3I69zjVzs6Q3MVm8JbypOTLlneT2eZscztT6ayi8=.aa4b37b7-6340-4b7e-9b8f-c11c745f99ae@github.com>
Message-ID: <VfMIdoW4vavJUasvBTth7KibZY01RI4bn89vj47i4aI=.7f493698-375e-45fe-a564-cbb4cb763e41@github.com>

On Mon, 19 Jan 2026 08:45:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Actually, on second thought, reverting the last commit will pass -g2 when the flag is not passed to configure, are you fine with that?
>
> Not really, I would like to pass `-g` if level is not overridden. I.e. to dodge bugs if toolchain does not support `-g2` for some weird reason, or `2` is not the actual default for some other weird reason. In the original change, that was the intent: either pass `-g` or `-g<num>` if user provided us with the num.

Got it. I'll think through how to go about doing this and get back when I'm done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29214#discussion_r2704130447

From duke at openjdk.org  Mon Jan 19 17:29:35 2026
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 Jan 2026 17:29:35 GMT
Subject: RFR: 8375649: idea.sh script adds source paths in a single, enormous, 
 line to jdk.iml.
Message-ID: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>

Allow replacement string to contain embedded newlines to split entries.
This turns output like:


    <content url="file:///home/david/dev/test/jdk">
      <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" /> ... another 10k chars on the end of this line ...


into:

    <content url="file:///home/david/dev/test/jdk">
      <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" />
      <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" />
      <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" />
      ... one entry per line ...

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

Commit messages:
 - 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml

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

PR: https://git.openjdk.org/jdk/pull/29305

From liach at openjdk.org  Mon Jan 19 17:43:34 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Jan 2026 17:43:34 GMT
Subject: RFR: 8375649: idea.sh script adds source paths in a single,
 enormous, line to jdk.iml
In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
Message-ID: <LLK-4WVIdrg6GyEMfxWzWNdz6zRdUgONhbdA9dYbhzw=.8efd0c14-0279-4201-818e-c87f34d404bb@github.com>

On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow replacement string to contain embedded newlines to split entries.
> This turns output like:
> 
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" /> ... another 10k chars on the end of this line ...
> 
> 
> into:
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" />
>       ... one entry per line ...

Should we just leave the newline in SOURCE_POSTFIX?

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

PR Comment: https://git.openjdk.org/jdk/pull/29305#issuecomment-3769511305

From duke at openjdk.org  Mon Jan 19 20:08:56 2026
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 Jan 2026 20:08:56 GMT
Subject: RFR: 8375649: idea.sh script adds source paths in a single,
 enormous, line to jdk.iml
In-Reply-To: <LLK-4WVIdrg6GyEMfxWzWNdz6zRdUgONhbdA9dYbhzw=.8efd0c14-0279-4201-818e-c87f34d404bb@github.com>
References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
 <LLK-4WVIdrg6GyEMfxWzWNdz6zRdUgONhbdA9dYbhzw=.8efd0c14-0279-4201-818e-c87f34d404bb@github.com>
Message-ID: <V9X4yy4lRAqtJ8G9qPj2-IJxFGKbeAVouCUeMfcO4lA=.a3400511-f72f-4ba0-9ada-9212186f1e4d@github.com>

On Mon, 19 Jan 2026 17:39:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should we just leave the newline in SOURCE_POSTFIX?

You end up with an extra blank line in the output if you do that, unless you mess with the template file as well.
The postfix is output +1 times more than the intermediate separator (fence posts).

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

PR Comment: https://git.openjdk.org/jdk/pull/29305#issuecomment-3769946094

From syan at openjdk.org  Tue Jan 20 13:23:57 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 20 Jan 2026 13:23:57 GMT
Subject: RFR: 8375683: Add notes for sctp tests
Message-ID: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>

Hi all,

The sctp tests need libsctp.so to be installed, otherwise those tests will report skipped. Seems that there is no help information to descripte how to run those tests. I think it's meaningful to add help information how to run those tests.

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

Commit messages:
 - 8375683: Add notes for sctp tests

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

PR: https://git.openjdk.org/jdk/pull/29320

From syan at openjdk.org  Tue Jan 20 13:29:06 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 20 Jan 2026 13:29:06 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v2]
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <8Ejqik7B-nIfqAwOn28utwcXBxscveMgcQYRmMFyOMM=.21994f3d-5663-4684-a2b3-ac22efb04d61@github.com>

> Hi all,
> 
> The sctp tests need libsctp.so to be installed, otherwise those tests will report skipped. Seems that there is no help information to descripte how to run those tests. I think it's meaningful to add help information how to run those tests.

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

  Update the testing.html through "make update-build-docs"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29320/files
  - new: https://git.openjdk.org/jdk/pull/29320/files/938932f2..0182358f

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

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

PR: https://git.openjdk.org/jdk/pull/29320

From syan at openjdk.org  Tue Jan 20 13:40:10 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 20 Jan 2026 13:40:10 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v3]
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <5agWbQUjgVm5UIpG0MNBffEgj1WfNUhl6LodCDBNmAs=.ac8f2e32-b814-4e57-9876-4bb0dbb9884a@github.com>

> Hi all,
> 
> The sctp tests need libsctp.so to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.

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

  Add index in testing.html

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29320/files
  - new: https://git.openjdk.org/jdk/pull/29320/files/0182358f..8f36333f

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

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

PR: https://git.openjdk.org/jdk/pull/29320

From aph at openjdk.org  Tue Jan 20 16:25:51 2026
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 20 Jan 2026 16:25:51 GMT
Subject: RFR: 8372701: Randomized profile counters [v8]
In-Reply-To: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
Message-ID: <LgdC7WOnsdk458BoE9v0rRvndQq_Ix8-ugRY0beI-Mc=.c58271b4-a8a4-4f24-8e7a-95dafbdd812a@github.com>

> Please use [this link](https://github.com/openjdk/jdk/pull/28541/changes?w=1) to view the files changed.
> 
> Profile counters scale very badly.
> 
> The overhead for profiled code isn't too bad with one thread, but as the thread count increases, things go wrong very quickly.
> 
> For example, here's a benchmark from the OpenJDK test suite, run at TieredLevel 3 with one thread, then three threads:
> 
> 
> Benchmark (randomized) Mode Cnt Score Error Units
> InterfaceCalls.test2ndInt5Types false avgt 4 27.468 ? 2.631 ns/op
> InterfaceCalls.test2ndInt5Types false avgt 4 240.010 ? 6.329 ns/op
> 
> 
> This slowdown is caused by high memory contention on the profile counters. Not only is this slow, but it can also lose profile counts.
> 
> This patch is for C1 only. It'd be easy to randomize C1 counters as well in another PR, if anyone thinks it's worth doing.
> 
> One other thing to note is that randomized profile counters degrade very badly with small decimation ratios. For example, using a ratio of 2 with `-XX:ProfileCaptureRatio=2` with a single thread results in
> 
> 
> Benchmark                        (randomized)  Mode  Cnt   Score   Error  Units
> InterfaceCalls.test2ndInt5Types         false  avgt    4  80.147 ? 9.991  ns/op
> 
> 
> The problem is that the branch prediction rate drops away very badly, leading to many mispredictions. It only really makes sense to use higher decimation ratios, e.g. 64.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Save and restore Profile RNG.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28541/files
  - new: https://git.openjdk.org/jdk/pull/28541/files/a1ed4b80..2a0cb808

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

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

PR: https://git.openjdk.org/jdk/pull/28541

From mbaesken at openjdk.org  Tue Jan 20 16:57:36 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 Jan 2026 16:57:36 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
In-Reply-To: <sX0LP4FDXxWUw5_4drz7bX1pYEANVMGMfW1_u5cT49k=.c884129b-248b-4f0e-b3bb-5529d7d415e9@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
 <sX0LP4FDXxWUw5_4drz7bX1pYEANVMGMfW1_u5cT49k=.c884129b-248b-4f0e-b3bb-5529d7d415e9@github.com>
Message-ID: <2f8zUNTiuF3qTPr2HNgX6xHjDZM6OA3rmOdDgKVvUKA=.43db1276-a80b-4a5c-8be6-41eb0f78bcca@github.com>

On Fri, 16 Jan 2026 15:45:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This set of files is expected for OpenJDK builds, but different vendors may be building the JDK under different license agreements and consequently, this set of files will differ. As an example, OracleJDK has the files `LICENSE` and `COPYRIGHT`.
> 
> I think we can check for the file `LICENSE`. If we are to check for the rest of the upper case files, it needs to be conditional on the LICENSE being GPL.


Good point !  Can I easily check from the test what kind of license it is ? Or if it is OpenJDK or OracleJDK (or a licensee JDK) ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29272#discussion_r2709228118

From kbarrett at openjdk.org  Tue Jan 20 18:46:53 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 20 Jan 2026 18:46:53 GMT
Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in
 MacOSX/bsd code
Message-ID: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>

Please review this change to MacOSX and bsd code to avoid using literal zero
as a null pointer constant, instead using nullptr.

Also disable that warning when building the gtest framework with clang,
similarly to what was done in JDK-8338154 for gcc.

Testing: mach5 tier1.  Also tested with additional build changes to enable the
warning.

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

Commit messages:
 - fix MacOSX -Wzero-as-null-pointer-constant warnings

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

PR: https://git.openjdk.org/jdk/pull/29329

From erikj at openjdk.org  Tue Jan 20 19:13:56 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Jan 2026 19:13:56 GMT
Subject: RFR: 8375649: idea.sh script adds source paths in a single,
 enormous, line to jdk.iml
In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
Message-ID: <x--aXSqHWCoWzHy8qDqhtaT0YrnaKeG2_VDl0Gt5QrA=.07046d01-7348-4d9a-b6d2-b2caa337cea1@github.com>

On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow replacement string to contain embedded newlines to split entries.
> This turns output like:
> 
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" /> ... another 10k chars on the end of this line ...
> 
> 
> into:
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" />
>       ... one entry per line ...

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29305#pullrequestreview-3683874366

From erikj at openjdk.org  Tue Jan 20 19:24:49 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Jan 2026 19:24:49 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v3]
In-Reply-To: <5agWbQUjgVm5UIpG0MNBffEgj1WfNUhl6LodCDBNmAs=.ac8f2e32-b814-4e57-9876-4bb0dbb9884a@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <5agWbQUjgVm5UIpG0MNBffEgj1WfNUhl6LodCDBNmAs=.ac8f2e32-b814-4e57-9876-4bb0dbb9884a@github.com>
Message-ID: <xLBrn3B2R7_p2LBz4lH_WtIAVLCZNIFLBExYKcl6UKg=.b7c6854b-9e23-4da9-a11e-3b7834568c28@github.com>

On Tue, 20 Jan 2026 13:40:10 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add index in testing.html

doc/testing.md line 649:

> 647: pre-installed. So the SCTP tests will be skipped by default. If you want to
> 648: enable the SCTP tests, you should install the SCTP library before run the
> 649: tests.

Suggested text:

The SCTP tests require the SCTP runtime library, which is often not installed by default in popular Linux distributions. Without this library, the SCTP tests will be skipped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2709751791

From erikj at openjdk.org  Tue Jan 20 19:26:56 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Jan 2026 19:26:56 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
In-Reply-To: <2f8zUNTiuF3qTPr2HNgX6xHjDZM6OA3rmOdDgKVvUKA=.43db1276-a80b-4a5c-8be6-41eb0f78bcca@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
 <sX0LP4FDXxWUw5_4drz7bX1pYEANVMGMfW1_u5cT49k=.c884129b-248b-4f0e-b3bb-5529d7d415e9@github.com>
 <2f8zUNTiuF3qTPr2HNgX6xHjDZM6OA3rmOdDgKVvUKA=.43db1276-a80b-4a5c-8be6-41eb0f78bcca@github.com>
Message-ID: <yUHJoM_vwV3ni1xaeU45Rf0i9rzSjTtFsgNc7_tw2f8=.55f7364b-b9fc-4f86-8d17-98d9eb9e7890@github.com>

On Tue, 20 Jan 2026 16:53:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/jdk/build/CheckFiles.java line 164:
>> 
>>> 162:         requiredFilesInLegalSubdirs.add("ADDITIONAL_LICENSE_INFO");
>>> 163:         requiredFilesInLegalSubdirs.add("ASSEMBLY_EXCEPTION");
>>> 164:         requiredFilesInLegalSubdirs.add("LICENSE");
>> 
>> This set of files is expected for OpenJDK builds, but different vendors may be building the JDK under different license agreements and consequently, this set of files will differ. As an example, OracleJDK has the files `LICENSE` and `COPYRIGHT`.
>> 
>> I think we can check for the file `LICENSE`. If we are to check for the rest of the upper case files, it needs to be conditional on the LICENSE being GPL.
>
>> This set of files is expected for OpenJDK builds, but different vendors may be building the JDK under different license agreements and consequently, this set of files will differ. As an example, OracleJDK has the files `LICENSE` and `COPYRIGHT`.
>> 
>> I think we can check for the file `LICENSE`. If we are to check for the rest of the upper case files, it needs to be conditional on the LICENSE being GPL.
> 
> 
> Good point !  Can I easily check from the test what kind of license it is ? Or if it is OpenJDK or OracleJDK (or a licensee JDK) ?

I would suggest checking the LICENSE file as you find it. If the first line is the below, then it's a GPL licensed build.


The GNU General Public License (GPL)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29272#discussion_r2709767420

From erikj at openjdk.org  Tue Jan 20 19:27:59 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Jan 2026 19:27:59 GMT
Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in
 MacOSX/bsd code
In-Reply-To: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
References: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
Message-ID: <0envuxcIleKParv5aWj9n3w8IPuau-2_cWgWOvkszQ4=.d86cceda-c2b6-444e-9a85-3d7f30f99f85@github.com>

On Tue, 20 Jan 2026 18:40:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to MacOSX and bsd code to avoid using literal zero
> as a null pointer constant, instead using nullptr.
> 
> Also disable that warning when building the gtest framework with clang,
> similarly to what was done in JDK-8338154 for gcc.
> 
> Testing: mach5 tier1.  Also tested with additional build changes to enable the
> warning.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29329#pullrequestreview-3683921917

From vyazici at openjdk.org  Tue Jan 20 19:41:49 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 Jan 2026 19:41:49 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v3]
In-Reply-To: <5agWbQUjgVm5UIpG0MNBffEgj1WfNUhl6LodCDBNmAs=.ac8f2e32-b814-4e57-9876-4bb0dbb9884a@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <5agWbQUjgVm5UIpG0MNBffEgj1WfNUhl6LodCDBNmAs=.ac8f2e32-b814-4e57-9876-4bb0dbb9884a@github.com>
Message-ID: <t_VUsX0SyZ5dwC-qjjGHeIh4SF0r3eYN6PD-GDV4Qck=.a67d4f27-f817-4ce8-958a-ea96505b92f8@github.com>

On Tue, 20 Jan 2026 13:40:10 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add index in testing.html

doc/testing.md line 651:

> 649: tests.
> 650: 
> 651: For apt-based distributions (Debian, Ubuntu, etc), try this:

*Nit:* I think `{apt,rpm}-based distributions` statements are imprecise. I'd rather word it as follows:

> For distributions using the `.deb` packaging format and the `apt` tool (such as Debian, Ubuntu, etc.), try this:

Likewise:

> For distributions using the `.rpm` packaging format and the `dnf` tool (such as Fedora, Red Hat, etc.), try this:

doc/testing.md line 660:

> 658: 
> 659: ```
> 660: sudo yum install -y lksctp-tools

AFAIK, `yum` is succeeded by `dnf`. We may consider using the equivalent `dnf` command instead.

doc/testing.md line 662:

> 660: sudo yum install -y lksctp-tools
> 661: sudo modprobe sctp
> 662: lsmod | grep sctp

AFAICT, these two steps apply to all type of distributions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2709750985
PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2709738706
PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2709798647

From syan at openjdk.org  Wed Jan 21 02:59:43 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Jan 2026 02:59:43 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v4]
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <xCoSyktXv8g4CCUsUiuAAZMI_B0z3kd4FeBLz9qUIC8=.b607f93d-c103-4b07-9a04-5d413df8e4b6@github.com>

> Hi all,
> 
> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.

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

  1. Update the description; 2. Use dnf instead of yum

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29320/files
  - new: https://git.openjdk.org/jdk/pull/29320/files/8f36333f..059ad876

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

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

PR: https://git.openjdk.org/jdk/pull/29320

From syan at openjdk.org  Wed Jan 21 03:14:39 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Jan 2026 03:14:39 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v5]
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <3t1XwCMiwJ_XXoMOzKLwUOpYPRxy2uG8rtv4UKjinBQ=.7ce53b48-a35d-4417-a3a9-23bcb9a17f04@github.com>

> Hi all,
> 
> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.

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

  1. Update apt/dnf description; 2. Add "sudo modprobe sctp" after apt install

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29320/files
  - new: https://git.openjdk.org/jdk/pull/29320/files/059ad876..63000fd8

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

  Stats: 13 lines in 2 files changed: 8 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/29320.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29320/head:pull/29320

PR: https://git.openjdk.org/jdk/pull/29320

From syan at openjdk.org  Wed Jan 21 03:14:41 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Jan 2026 03:14:41 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v3]
In-Reply-To: <xLBrn3B2R7_p2LBz4lH_WtIAVLCZNIFLBExYKcl6UKg=.b7c6854b-9e23-4da9-a11e-3b7834568c28@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <5agWbQUjgVm5UIpG0MNBffEgj1WfNUhl6LodCDBNmAs=.ac8f2e32-b814-4e57-9876-4bb0dbb9884a@github.com>
 <xLBrn3B2R7_p2LBz4lH_WtIAVLCZNIFLBExYKcl6UKg=.b7c6854b-9e23-4da9-a11e-3b7834568c28@github.com>
Message-ID: <PrhwjO9M7HiEuYeGfu1NoxoZksKinBKJ1PxlF0HaiCk=.7ba22a28-3d47-4fc2-8760-00e8b644abe7@github.com>

On Tue, 20 Jan 2026 19:17:43 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add index in testing.html
>
> doc/testing.md line 649:
> 
>> 647: pre-installed. So the SCTP tests will be skipped by default. If you want to
>> 648: enable the SCTP tests, you should install the SCTP library before run the
>> 649: tests.
> 
> Suggested text:
> 
> The SCTP tests require the SCTP runtime library, which is often not installed by default in popular Linux distributions. Without this library, the SCTP tests will be skipped.

Thanks for the suggestion. The text has been updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2710795541

From syan at openjdk.org  Wed Jan 21 03:14:43 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Jan 2026 03:14:43 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v3]
In-Reply-To: <t_VUsX0SyZ5dwC-qjjGHeIh4SF0r3eYN6PD-GDV4Qck=.a67d4f27-f817-4ce8-958a-ea96505b92f8@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <5agWbQUjgVm5UIpG0MNBffEgj1WfNUhl6LodCDBNmAs=.ac8f2e32-b814-4e57-9876-4bb0dbb9884a@github.com>
 <t_VUsX0SyZ5dwC-qjjGHeIh4SF0r3eYN6PD-GDV4Qck=.a67d4f27-f817-4ce8-958a-ea96505b92f8@github.com>
Message-ID: <rl2cKWTG8HL1Nk6AiC5WCYcatiUYnPk1C2TuSXy4l_E=.7c93fc88-ac17-4d18-ad36-1460c82d445f@github.com>

On Tue, 20 Jan 2026 19:17:25 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add index in testing.html
>
> doc/testing.md line 651:
> 
>> 649: tests.
>> 650: 
>> 651: For apt-based distributions (Debian, Ubuntu, etc), try this:
> 
> *Nit:* I think `{apt,rpm}-based distributions` statements are imprecise. I'd rather word it as follows:
> 
>> For distributions using the `.deb` packaging format and the `apt` tool (such as Debian, Ubuntu, etc.), try this:
> 
> Likewise:
> 
>> For distributions using the `.rpm` packaging format and the `dnf` tool (such as Fedora, Red Hat, etc.), try this:

Thanks for the suggestions. The descriptions has been updated.

> doc/testing.md line 660:
> 
>> 658: 
>> 659: ```
>> 660: sudo yum install -y lksctp-tools
> 
> AFAIK, `yum` is succeeded by `dnf`. We may consider using the equivalent `dnf` command instead.

Thanks. Fixed.

> doc/testing.md line 662:
> 
>> 660: sudo yum install -y lksctp-tools
>> 661: sudo modprobe sctp
>> 662: lsmod | grep sctp
> 
> AFAICT, these two steps apply to all type of distributions.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2710797321
PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2710795933
PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2710797861

From dholmes at openjdk.org  Wed Jan 21 05:16:56 2026
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Jan 2026 05:16:56 GMT
Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in
 MacOSX/bsd code
In-Reply-To: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
References: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
Message-ID: <fYcaaFq8AYo45yPzuGgybryg346OnrpSgetLXrbbNAs=.d2bfe2e8-8ead-43c6-9cb4-0b9c7f9e0a00@github.com>

On Tue, 20 Jan 2026 18:40:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to MacOSX and bsd code to avoid using literal zero
> as a null pointer constant, instead using nullptr.
> 
> Also disable that warning when building the gtest framework with clang,
> similarly to what was done in JDK-8338154 for gcc.
> 
> Testing: mach5 tier1.  Also tested with additional build changes to enable the
> warning.

Looks good.

If we don't already have the warning disabled, why are these occurrences not already causing warnings (and thus errors) in clang builds??

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29329#pullrequestreview-3685377964

From kbarrett at openjdk.org  Wed Jan 21 06:02:34 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 Jan 2026 06:02:34 GMT
Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in
 MacOSX/bsd code
In-Reply-To: <fYcaaFq8AYo45yPzuGgybryg346OnrpSgetLXrbbNAs=.d2bfe2e8-8ead-43c6-9cb4-0b9c7f9e0a00@github.com>
References: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
 <fYcaaFq8AYo45yPzuGgybryg346OnrpSgetLXrbbNAs=.d2bfe2e8-8ead-43c6-9cb4-0b9c7f9e0a00@github.com>
Message-ID: <fzA4jfOCvz2UXVMMo-BwCtPHwX_9Mb5CCzuycKJYRWo=.9060fc03-52d5-41aa-9b7a-963f50dfbe30@github.com>

On Wed, 21 Jan 2026 05:14:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If we don't already have the warning disabled, why are these occurrences not already causing warnings (and thus errors) in clang builds??

Because we aren't currently enabling the warning.  I have a build change to enable the warning ready to propose once
the warnings that would be triggered by it have been addressed.  That's what I'm using to find these.  Note that when
I started working on this there were thousands of warnings.

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

PR Comment: https://git.openjdk.org/jdk/pull/29329#issuecomment-3776345311

From kbarrett at openjdk.org  Wed Jan 21 06:05:46 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 Jan 2026 06:05:46 GMT
Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in
 MacOSX/bsd code
In-Reply-To: <0envuxcIleKParv5aWj9n3w8IPuau-2_cWgWOvkszQ4=.d86cceda-c2b6-444e-9a85-3d7f30f99f85@github.com>
References: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
 <0envuxcIleKParv5aWj9n3w8IPuau-2_cWgWOvkszQ4=.d86cceda-c2b6-444e-9a85-3d7f30f99f85@github.com>
Message-ID: <D_ODB57j7-iNm-f38P9w4DckH1XJ2HeKBCRP8Se-MqU=.77c92b1a-e4e4-4c5c-bc39-110aafc3f772@github.com>

On Tue, 20 Jan 2026 19:24:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Please review this change to MacOSX and bsd code to avoid using literal zero
>> as a null pointer constant, instead using nullptr.
>> 
>> Also disable that warning when building the gtest framework with clang,
>> similarly to what was done in JDK-8338154 for gcc.
>> 
>> Testing: mach5 tier1.  Also tested with additional build changes to enable the
>> warning.
>
> Marked as reviewed by erikj (Reviewer).

Thanks for reviews @erikj79 and @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/29329#issuecomment-3776351783

From kbarrett at openjdk.org  Wed Jan 21 06:08:38 2026
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 Jan 2026 06:08:38 GMT
Subject: Integrated: 8375738: Fix -Wzero-as-null-pointer-constant warnings in
 MacOSX/bsd code
In-Reply-To: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
References: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
Message-ID: <lcSPz6EBopCgD_BCAaCwtHN0B0_7R2_Q_MfXr0DhDgE=.b50085be-d52c-4294-a653-19691f9e3950@github.com>

On Tue, 20 Jan 2026 18:40:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to MacOSX and bsd code to avoid using literal zero
> as a null pointer constant, instead using nullptr.
> 
> Also disable that warning when building the gtest framework with clang,
> similarly to what was done in JDK-8338154 for gcc.
> 
> Testing: mach5 tier1.  Also tested with additional build changes to enable the
> warning.

This pull request has now been integrated.

Changeset: b5727d27
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5727d27622e1e321733f8d0e606b366984104be
Stats:     6 lines in 3 files changed: 1 ins; 0 del; 5 mod

8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code

Reviewed-by: erikj, dholmes

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

PR: https://git.openjdk.org/jdk/pull/29329

From dholmes at openjdk.org  Wed Jan 21 06:10:44 2026
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Jan 2026 06:10:44 GMT
Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in
 MacOSX/bsd code
In-Reply-To: <fzA4jfOCvz2UXVMMo-BwCtPHwX_9Mb5CCzuycKJYRWo=.9060fc03-52d5-41aa-9b7a-963f50dfbe30@github.com>
References: <ZpoNO37UDU22m_M501e8RijT4VjOQPkXDoSN0zZrXw8=.fcb8edbf-e755-4836-abe3-b5499cda3236@github.com>
 <fYcaaFq8AYo45yPzuGgybryg346OnrpSgetLXrbbNAs=.d2bfe2e8-8ead-43c6-9cb4-0b9c7f9e0a00@github.com>
 <fzA4jfOCvz2UXVMMo-BwCtPHwX_9Mb5CCzuycKJYRWo=.9060fc03-52d5-41aa-9b7a-963f50dfbe30@github.com>
Message-ID: <iITpSHUvPcVo5Ud88jwKaWVVON8MES9octXyPfy7GJQ=.b61d1468-23d5-45ba-8a2c-9a631ec5f9ca@github.com>

On Wed, 21 Jan 2026 06:00:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Because we aren't currently enabling the warning. 

Sorry, the "gtest" part didn't register with me,

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

PR Comment: https://git.openjdk.org/jdk/pull/29329#issuecomment-3776364384

From jwaters at openjdk.org  Wed Jan 21 06:24:39 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jan 2026 06:24:39 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v3]
In-Reply-To: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
Message-ID: <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>

> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Use auto for default in flags-cflags.m4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29214/files
  - new: https://git.openjdk.org/jdk/pull/29214/files/d6a1e78d..37d8c9f4

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

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

PR: https://git.openjdk.org/jdk/pull/29214

From vyazici at openjdk.org  Wed Jan 21 08:16:09 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 Jan 2026 08:16:09 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v5]
In-Reply-To: <3t1XwCMiwJ_XXoMOzKLwUOpYPRxy2uG8rtv4UKjinBQ=.7ce53b48-a35d-4417-a3a9-23bcb9a17f04@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <3t1XwCMiwJ_XXoMOzKLwUOpYPRxy2uG8rtv4UKjinBQ=.7ce53b48-a35d-4417-a3a9-23bcb9a17f04@github.com>
Message-ID: <x0GUaT2HK2Nv0qE0PXfdJw6gkzsp7vskRf2WkyCL3RI=.2c5dfc77-9ab7-48dd-b4f2-23cce8482720@github.com>

On Wed, 21 Jan 2026 03:14:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. Update apt/dnf description; 2. Add "sudo modprobe sctp" after apt install

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29320#pullrequestreview-3685862308

From mbaesken at openjdk.org  Wed Jan 21 09:18:19 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jan 2026 09:18:19 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
 [v2]
In-Reply-To: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
Message-ID: <AdYDrtXugrvW9eNu3IgrUBVPntCS4H9Pd1-ls5s4yHE=.5b344ce2-7c37-4804-a657-87bfb6870b8f@github.com>

> We currently expect certain files in the legal folder of the jdk image.
> This should be checked by a test.
> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  GPL JDK image has different files in the legal subfolders

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29272/files
  - new: https://git.openjdk.org/jdk/pull/29272/files/ef25393f..bf743de2

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

  Stats: 24 lines in 1 file changed: 21 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29272.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29272/head:pull/29272

PR: https://git.openjdk.org/jdk/pull/29272

From erikj at openjdk.org  Wed Jan 21 14:30:41 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jan 2026 14:30:41 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v3]
In-Reply-To: <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
Message-ID: <eVOuWlKxjPxItB58UTrs5n9ik6bkFabb3CFiBt7It6Y=.07863d93-b36c-413f-847d-c59de28b2a16@github.com>

On Wed, 21 Jan 2026 06:24:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use auto for default in flags-cflags.m4

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29214#pullrequestreview-3687540751

From erikj at openjdk.org  Wed Jan 21 14:35:39 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jan 2026 14:35:39 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v5]
In-Reply-To: <3t1XwCMiwJ_XXoMOzKLwUOpYPRxy2uG8rtv4UKjinBQ=.7ce53b48-a35d-4417-a3a9-23bcb9a17f04@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <3t1XwCMiwJ_XXoMOzKLwUOpYPRxy2uG8rtv4UKjinBQ=.7ce53b48-a35d-4417-a3a9-23bcb9a17f04@github.com>
Message-ID: <ZAK-bI6jhaTXZiBN72TmKC1TUTJfsCCU-OkOggoYB6s=.c9df0bc2-a7f8-4742-8642-a3d2bce5a26b@github.com>

On Wed, 21 Jan 2026 03:14:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. Update apt/dnf description; 2. Add "sudo modprobe sctp" after apt install

doc/testing.html line 629:

> 627: by default in popular Linux distributions. Without this library,
> 628: the SCTP tests will be skipped. If you want to enable the SCTP tests,
> 629: you should install the SCTP library before run the tests.</p>

These line lengths look uneven. The html generator tool would not generate it like that. If I run `make update-build-docs` I get a diff on these lines. Please make sure the html files you are committing are exactly what the tool would generate to avoid creating diffs for the next person editing these files.

doc/testing.md line 649:

> 647: by default in popular Linux distributions. Without this library,
> 648: the SCTP tests will be skipped. If you want to enable the SCTP tests,
> 649: you should install the SCTP library before run the tests.

Suggestion:

you should install the SCTP library before running the tests.


Also please fix line breaks so line lengths are uniform and match the rest of the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2712838402
PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2712825228

From erikj at openjdk.org  Wed Jan 21 14:45:37 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jan 2026 14:45:37 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
 [v2]
In-Reply-To: <yUHJoM_vwV3ni1xaeU45Rf0i9rzSjTtFsgNc7_tw2f8=.55f7364b-b9fc-4f86-8d17-98d9eb9e7890@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
 <sX0LP4FDXxWUw5_4drz7bX1pYEANVMGMfW1_u5cT49k=.c884129b-248b-4f0e-b3bb-5529d7d415e9@github.com>
 <2f8zUNTiuF3qTPr2HNgX6xHjDZM6OA3rmOdDgKVvUKA=.43db1276-a80b-4a5c-8be6-41eb0f78bcca@github.com>
 <yUHJoM_vwV3ni1xaeU45Rf0i9rzSjTtFsgNc7_tw2f8=.55f7364b-b9fc-4f86-8d17-98d9eb9e7890@github.com>
Message-ID: <OaJ9USjeiO_E5tURHoUBeM_BvZbhj9bop28WsQEUIas=.d44a585d-4d31-4b41-be0b-3cc7732b7a2c@github.com>

On Tue, 20 Jan 2026 19:23:10 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> This set of files is expected for OpenJDK builds, but different vendors may be building the JDK under different license agreements and consequently, this set of files will differ. As an example, OracleJDK has the files `LICENSE` and `COPYRIGHT`.
>>> 
>>> I think we can check for the file `LICENSE`. If we are to check for the rest of the upper case files, it needs to be conditional on the LICENSE being GPL.
>> 
>> 
>> Good point !  Can I easily check from the test what kind of license it is ? Or if it is OpenJDK or OracleJDK (or a licensee JDK) ?
>
> I would suggest checking the LICENSE file as you find it. If the first line is the below, then it's a GPL licensed build.
> 
> 
> The GNU General Public License (GPL)

At least the OracleJDK also has the file COPYRIGHT. I don't think this open test should verify that, but it also can't make assumptions on what files aren't allowed in non GPL builds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29272#discussion_r2712885789

From mbaesken at openjdk.org  Wed Jan 21 14:49:22 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jan 2026 14:49:22 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
 [v2]
In-Reply-To: <OaJ9USjeiO_E5tURHoUBeM_BvZbhj9bop28WsQEUIas=.d44a585d-4d31-4b41-be0b-3cc7732b7a2c@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
 <sX0LP4FDXxWUw5_4drz7bX1pYEANVMGMfW1_u5cT49k=.c884129b-248b-4f0e-b3bb-5529d7d415e9@github.com>
 <2f8zUNTiuF3qTPr2HNgX6xHjDZM6OA3rmOdDgKVvUKA=.43db1276-a80b-4a5c-8be6-41eb0f78bcca@github.com>
 <yUHJoM_vwV3ni1xaeU45Rf0i9rzSjTtFsgNc7_tw2f8=.55f7364b-b9fc-4f86-8d17-98d9eb9e7890@github.com>
 <OaJ9USjeiO_E5tURHoUBeM_BvZbhj9bop28WsQEUIas=.d44a585d-4d31-4b41-be0b-3cc7732b7a2c@github.com>
Message-ID: <7OQ-RelpnzSd55JF9wbgCxAnkqbwMlgwryDzkrfNCu0=.16fad079-6bb7-4e41-8bf7-1efa56c0a555@github.com>

On Wed, 21 Jan 2026 14:42:35 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> At least the OracleJDK also has the file COPYRIGHT. I don't think this open test should verify that, but it also can't make assumptions on what files aren't allowed in non GPL builds.

So maybe just do the whole  'legal' - folder check for GPL based JDK images ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29272#discussion_r2712899964

From erikj at openjdk.org  Wed Jan 21 15:06:15 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jan 2026 15:06:15 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
 [v2]
In-Reply-To: <7OQ-RelpnzSd55JF9wbgCxAnkqbwMlgwryDzkrfNCu0=.16fad079-6bb7-4e41-8bf7-1efa56c0a555@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
 <sX0LP4FDXxWUw5_4drz7bX1pYEANVMGMfW1_u5cT49k=.c884129b-248b-4f0e-b3bb-5529d7d415e9@github.com>
 <2f8zUNTiuF3qTPr2HNgX6xHjDZM6OA3rmOdDgKVvUKA=.43db1276-a80b-4a5c-8be6-41eb0f78bcca@github.com>
 <yUHJoM_vwV3ni1xaeU45Rf0i9rzSjTtFsgNc7_tw2f8=.55f7364b-b9fc-4f86-8d17-98d9eb9e7890@github.com>
 <OaJ9USjeiO_E5tURHoUBeM_BvZbhj9bop28WsQEUIas=.d44a585d-4d31-4b41-be0b-3cc7732b7a2c@github.com>
 <7OQ-RelpnzSd55JF9wbgCxAnkqbwMlgwryDzkrfNCu0=.16fad079-6bb7-4e41-8bf7-1efa56c0a555@github.com>
Message-ID: <1YFxo9A82I6oId6mspQ2B8SgsJqsTHiKju4frVNl4a4=.c2d37d4a-fa44-4057-b320-8c33125f5a38@github.com>

On Wed, 21 Jan 2026 14:45:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> At least the OracleJDK also has the file COPYRIGHT. I don't think this open test should verify that, but it also can't make assumptions on what files aren't allowed in non GPL builds.
>
>> At least the OracleJDK also has the file COPYRIGHT. I don't think this open test should verify that, but it also can't make assumptions on what files aren't allowed in non GPL builds.
> 
> So maybe just do the whole  'legal' - folder check for GPL based JDK images ?

Yes, that is ok with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29272#discussion_r2712970570

From mbaesken at openjdk.org  Wed Jan 21 16:04:44 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jan 2026 16:04:44 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
 [v3]
In-Reply-To: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
Message-ID: <cqNzhglLQ5rEODBczpIVxxsHrOUYtDMrsGsyq2NWFAY=.da3b544e-1296-4f6a-afda-29a2e9d3692e@github.com>

> We currently expect certain files in the legal folder of the jdk image.
> This should be checked by a test.
> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Check legal dir only for GPL based images

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29272/files
  - new: https://git.openjdk.org/jdk/pull/29272/files/bf743de2..aa8f5400

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

  Stats: 21 lines in 1 file changed: 8 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29272.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29272/head:pull/29272

PR: https://git.openjdk.org/jdk/pull/29272

From shade at openjdk.org  Wed Jan 21 16:13:22 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Jan 2026 16:13:22 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v3]
In-Reply-To: <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
Message-ID: <RG7A3-CmgYGet2A3qaEnftUWZkyBSTzc53zrOvJWvlU=.8cf98439-9eca-4a2c-918f-9f1604b013b8@github.com>

On Wed, 21 Jan 2026 06:24:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use auto for default in flags-cflags.m4

Looks fine, but I want to sanity-test it on my builds to confirm it works as intended. Give me a few hours, maybe a day.

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

PR Comment: https://git.openjdk.org/jdk/pull/29214#issuecomment-3779241229

From jwaters at openjdk.org  Wed Jan 21 16:35:13 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jan 2026 16:35:13 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v3]
In-Reply-To: <RG7A3-CmgYGet2A3qaEnftUWZkyBSTzc53zrOvJWvlU=.8cf98439-9eca-4a2c-918f-9f1604b013b8@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
 <RG7A3-CmgYGet2A3qaEnftUWZkyBSTzc53zrOvJWvlU=.8cf98439-9eca-4a2c-918f-9f1604b013b8@github.com>
Message-ID: <E69PKl3zIdVqp-lTVwuDcZ8MUy7rUoK58sc6ebGY9o4=.b45d396d-698c-41a5-b75b-c85cc184a68f@github.com>

On Wed, 21 Jan 2026 16:09:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks fine, but I want to sanity-test it on my builds to confirm it works as intended. Give me a few hours, maybe a day.

No worries! Please do, I am always deathly afraid that it works on my device and not on others, I don't mind at all.

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

PR Comment: https://git.openjdk.org/jdk/pull/29214#issuecomment-3779445091

From liach at openjdk.org  Wed Jan 21 16:35:14 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jan 2026 16:35:14 GMT
Subject: RFR: 8375649: idea.sh script adds source paths in a single,
 enormous, line to jdk.iml
In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
Message-ID: <obBA-bkUl226hsclXIwOl3WDE8tAw60CtHqY9Q4z-Zw=.01e167ca-e34c-4cff-94fa-7c8859faba6c@github.com>

On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow replacement string to contain embedded newlines to split entries.
> This turns output like:
> 
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" /> ... another 10k chars on the end of this line ...
> 
> 
> into:
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" />
>       ... one entry per line ...

In addition, I see extra spaces presumably for indent after the `\n` - are we sure the number of spaces is correct? Is there a reason we don't need this indent for the 1st line?

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

PR Comment: https://git.openjdk.org/jdk/pull/29305#issuecomment-3779447248

From erikj at openjdk.org  Wed Jan 21 17:31:00 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jan 2026 17:31:00 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
 [v3]
In-Reply-To: <cqNzhglLQ5rEODBczpIVxxsHrOUYtDMrsGsyq2NWFAY=.da3b544e-1296-4f6a-afda-29a2e9d3692e@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
 <cqNzhglLQ5rEODBczpIVxxsHrOUYtDMrsGsyq2NWFAY=.da3b544e-1296-4f6a-afda-29a2e9d3692e@github.com>
Message-ID: <1YXdSb3QN96MC0aEGhdtARejlymn9EBX6iRoTbyIPSU=.522dc876-49d7-4c65-8b6e-3ffa6d9fd515@github.com>

On Wed, 21 Jan 2026 16:04:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect certain files in the legal folder of the jdk image.
>> This should be checked by a test.
>> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check legal dir only for GPL based images

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29272#pullrequestreview-3688504491

From shade at openjdk.org  Wed Jan 21 18:46:04 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Jan 2026 18:46:04 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v3]
In-Reply-To: <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
Message-ID: <w0D3uXhXjyrypL1j10wx9TV8Srx-6xax_EgtJwnLwd4=.8b395f6d-66d7-4f1c-a9d8-32bea3b7b8f1@github.com>

On Wed, 21 Jan 2026 06:24:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use auto for default in flags-cflags.m4

Seems to work as expected:


$ du -sh build/linux-x86_64-server-fastdebug/images/jdk/

# --- Current mainline

# level=1
637M	build/linux-x86_64-server-fastdebug/images/jdk/

# level=2
1.7G	build/linux-x86_64-server-fastdebug/images/jdk/

# level=3
1.8G	build/linux-x86_64-server-fastdebug/images/jdk/

# default
1.7G	build/linux-x86_64-server-fastdebug/images/jdk/


# --- This PR

# level=1
637M	build/linux-x86_64-server-fastdebug/images/jdk/

# level=2
1.7G	build/linux-x86_64-server-fastdebug/images/jdk/

# level=3
1.8G	build/linux-x86_64-server-fastdebug/images/jdk/

# default
1.7G	build/linux-x86_64-server-fastdebug/images/jdk/

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29214#pullrequestreview-3688788734

From mcimadamore at openjdk.org  Wed Jan 21 19:02:10 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Jan 2026 19:02:10 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <un--qP6HOPN7VyxKxZLIUwJbVHgZbqZ_dwQYYbdF004=.4dee79fb-20f2-47ef-8965-a1e01e0e30c5@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
 <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>
 <un--qP6HOPN7VyxKxZLIUwJbVHgZbqZ_dwQYYbdF004=.4dee79fb-20f2-47ef-8965-a1e01e0e30c5@github.com>
Message-ID: <BKAxFQOF2jFU1Ciwys3v_QX3FP6BNNTjBVdFYOo4Gvc=.6e63cb2c-8eb2-4bc7-95fb-7fe70c2f1c7d@github.com>

On Thu, 15 Jan 2026 23:07:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to  include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633?
>
> For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs`  for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions).

I believe the proposed patch to be reasonable given the limitations we already covered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2713938064

From weijun at openjdk.org  Wed Jan 21 19:23:18 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 19:23:18 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v9]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <UCEEkYIgcdU1sgsHoGcJ1VKn3a4bcmnlhtspj5_6s3I=.5242b6cc-d0f2-48cf-8814-9841faa72ab8@github.com>

> Rewrite the native calls with FFM.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  adding TheRealMDoerr's workaround

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/bf91106e..99604e06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=07-08

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

PR: https://git.openjdk.org/jdk/pull/28931

From weijun at openjdk.org  Wed Jan 21 19:23:20 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 19:23:20 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
Message-ID: <Yh8hK0WYmQOEBqJXDNeGjngi6aDYQho5ZHJn9L5kCRU=.90d0bc47-fdc7-4a8c-93f8-5fc002014281@github.com>

On Tue, 30 Dec 2025 23:00:31 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite without jextract
>
> I've made some AIX experiments.

Hi @TheRealMDoerr, I've included your workaround. Please try it on your systems. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3780725018

From mdoerr at openjdk.org  Wed Jan 21 19:23:21 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 19:23:21 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <BKAxFQOF2jFU1Ciwys3v_QX3FP6BNNTjBVdFYOo4Gvc=.6e63cb2c-8eb2-4bc7-95fb-7fe70c2f1c7d@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
 <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>
 <un--qP6HOPN7VyxKxZLIUwJbVHgZbqZ_dwQYYbdF004=.4dee79fb-20f2-47ef-8965-a1e01e0e30c5@github.com>
 <BKAxFQOF2jFU1Ciwys3v_QX3FP6BNNTjBVdFYOo4Gvc=.6e63cb2c-8eb2-4bc7-95fb-7fe70c2f1c7d@github.com>
Message-ID: <f6A-D7YC82mfj80xSth99JvhOhvnSEptvzjgDaQp3EM=.e7e9f2d4-4c20-43a3-a336-11d025ad74d9@github.com>

On Wed, 21 Jan 2026 18:59:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs`  for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions).
>
> I believe the proposed patch to be reasonable given the limitations we already covered.

It would be nice to add a comment like:
We need to pass the uid as uint32_t which requires zero extension on some 64-bit platforms. JDK-8336664 is not yet available, so we extend it here for these platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714007305

From mdoerr at openjdk.org  Wed Jan 21 19:25:10 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 19:25:10 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8]
In-Reply-To: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>
Message-ID: <rYzkfr_D0QYPxOZ2sa0znr0lmwv-leFnHuHn3UQAtiE=.748b6cfb-8dfb-45a1-ba9f-f37ab99c8900@github.com>

On Tue, 13 Jan 2026 21:17:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new naming style; use VarHandle to access fields

Ah, you already added a comment referring to JDK-8336664. Looks good! Thanks a lot for taking care of it! We'll run tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3780744019

From weijun at openjdk.org  Wed Jan 21 19:39:49 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 19:39:49 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>

> Rewrite the native calls with FFM.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  unnecessary initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/99604e06..0aec40c0

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

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

PR: https://git.openjdk.org/jdk/pull/28931

From mdoerr at openjdk.org  Wed Jan 21 20:32:14 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 20:32:14 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
Message-ID: <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>

On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary initialization

The test has passed on linux PPC64le and AIX. @offamitkumar: Do you want to run the test on s390?
I think it's good.
The JBS issue says "See if it's a better alternative of JNI." Is there any comparison or evaluation planned?

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118:

> 116:             = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow(
> 117:                             OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
> 118:                     FunctionDescriptor.of(C_INT,

Indentation could be improved, here.

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

PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3689250234
PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714211087

From weijun at openjdk.org  Wed Jan 21 21:04:40 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 21:04:40 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
 <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>
Message-ID: <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com>

On Wed, 21 Jan 2026 20:23:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   unnecessary initialization
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118:
> 
>> 116:             = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow(
>> 117:                             OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>> 118:                     FunctionDescriptor.of(C_INT,
> 
> Indentation could be improved, here.

Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I don't think that's correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714326021

From weijun at openjdk.org  Wed Jan 21 21:13:58 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 21:13:58 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
 <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>
 <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com>
Message-ID: <iqmJs8j886RTTMgrXLoLOqdgh5yDoskM0UkzKMtbGyw=.d23aaf74-2479-4c32-9e8b-96cccf9a06f7@github.com>

On Wed, 21 Jan 2026 21:01:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118:
>> 
>>> 116:             = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow(
>>> 117:                             OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>>> 118:                     FunctionDescriptor.of(C_INT,
>> 
>> Indentation could be improved, here.
>
> Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I think that's misleading.

As for whether it's a better alternative of JNI, FFM is usually considered at least as fast as JNI. In this case, on my Mac, the FFM version is much much faster. I guess the main reason is while the C code is quite small it calls back to Java object manipulation too much.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714356450

From mdoerr at openjdk.org  Wed Jan 21 21:32:11 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 21:32:11 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
Message-ID: <7sNwX027pt2Pc7AHHZ9xBcTQe34A4UOAZwKGQZv1sZw=.a71ed3a2-d75d-4a2b-8f7b-7ebd8a5677a4@github.com>

On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary initialization

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3689482675

From mdoerr at openjdk.org  Wed Jan 21 21:32:12 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 21:32:12 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <iqmJs8j886RTTMgrXLoLOqdgh5yDoskM0UkzKMtbGyw=.d23aaf74-2479-4c32-9e8b-96cccf9a06f7@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
 <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>
 <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com>
 <iqmJs8j886RTTMgrXLoLOqdgh5yDoskM0UkzKMtbGyw=.d23aaf74-2479-4c32-9e8b-96cccf9a06f7@github.com>
Message-ID: <roADzDg--JnkPxUVHeq-hlkVHpjSL3fEkRCFYxcC4G8=.69a423b6-9ee5-49df-acb1-ef1e397464fe@github.com>

On Wed, 21 Jan 2026 21:11:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I think that's misleading.
>
> As for whether it's a better alternative of JNI, FFM is usually considered at least as fast as JNI. In this case, on my Mac, the FFM version is much much faster. I guess the main reason is while the C code is quite small it calls back to Java object manipulation too much.

> IntelliJ IDEA unindents the FunctionDescriptor.of(...) block but I think that's misleading.

That's what I thought.

Ok. Another advantage is that we don't need the .c file any more. If performance matters, we could still tune it by using the critical option. But I guess it's fast enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714401065

From ascarpino at openjdk.org  Thu Jan 22 00:58:40 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Jan 2026 00:58:40 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
Message-ID: <LB7K8sVYjox3LZ5K5lQOaSutPndTv4RiBRGV-S8Ijp0=.414a82ca-11a5-4b26-a6f9-14e48e6cd656@github.com>

On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary initialization

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3690107628

From syan at openjdk.org  Thu Jan 22 02:42:16 2026
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 Jan 2026 02:42:16 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v6]
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <2yR79-gCwnLPS4G9qYzjjZmdWq9Pkwzbfk8Dnn27CTU=.90a84593-b0b0-4c6c-87c6-3876ac1d3a2e@github.com>

> Hi all,
> 
> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.

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

  1.Fix the typo running; 2. Make line length more uniform

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29320/files
  - new: https://git.openjdk.org/jdk/pull/29320/files/63000fd8..2ebd647f

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

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

PR: https://git.openjdk.org/jdk/pull/29320

From syan at openjdk.org  Thu Jan 22 02:49:40 2026
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 Jan 2026 02:49:40 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v7]
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <g7GoEkR8QOduHY9T_2Q6haQhnlr4aldkA-NS9t-aRng=.09724780-0e6e-400b-8d39-a334655be54f@github.com>

> Hi all,
> 
> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.

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

  Regenerate testing.html by "make update-build-docs"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29320/files
  - new: https://git.openjdk.org/jdk/pull/29320/files/2ebd647f..4fc0f17f

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

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

PR: https://git.openjdk.org/jdk/pull/29320

From syan at openjdk.org  Thu Jan 22 02:49:43 2026
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 Jan 2026 02:49:43 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v5]
In-Reply-To: <ZAK-bI6jhaTXZiBN72TmKC1TUTJfsCCU-OkOggoYB6s=.c9df0bc2-a7f8-4742-8642-a3d2bce5a26b@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <3t1XwCMiwJ_XXoMOzKLwUOpYPRxy2uG8rtv4UKjinBQ=.7ce53b48-a35d-4417-a3a9-23bcb9a17f04@github.com>
 <ZAK-bI6jhaTXZiBN72TmKC1TUTJfsCCU-OkOggoYB6s=.c9df0bc2-a7f8-4742-8642-a3d2bce5a26b@github.com>
Message-ID: <oFyUcUdh1bJp33ZQm4NxSzWakyn7uSC72kEFPWjDOYE=.5ecc9138-e082-4792-9958-43857bdedde1@github.com>

On Wed, 21 Jan 2026 14:31:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. Update apt/dnf description; 2. Add "sudo modprobe sctp" after apt install
>
> doc/testing.html line 629:
> 
>> 627: by default in popular Linux distributions. Without this library,
>> 628: the SCTP tests will be skipped. If you want to enable the SCTP tests,
>> 629: you should install the SCTP library before run the tests.</p>
> 
> These line lengths look uneven. The html generator tool would not generate it like that. If I run `make update-build-docs` I get a diff on these lines. Please make sure the html files you are committing are exactly what the tool would generate to avoid creating diffs for the next person editing these files.

testing.html has been regenerated by `make update-build-docs`. And only the changes of SCTP been keeped.

> doc/testing.md line 649:
> 
>> 647: by default in popular Linux distributions. Without this library,
>> 648: the SCTP tests will be skipped. If you want to enable the SCTP tests,
>> 649: you should install the SCTP library before run the tests.
> 
> Suggestion:
> 
> you should install the SCTP library before running the tests.
> 
> 
> Also please fix line breaks so line lengths are uniform and match the rest of the file.

Thanks. The typo has been fixed. And the line length are uniformed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2715101102
PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2715098756

From mbaesken at openjdk.org  Thu Jan 22 08:53:35 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jan 2026 08:53:35 GMT
Subject: RFR: 8375458: Check legal folder of JDK image for unwanted files
 [v3]
In-Reply-To: <cqNzhglLQ5rEODBczpIVxxsHrOUYtDMrsGsyq2NWFAY=.da3b544e-1296-4f6a-afda-29a2e9d3692e@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
 <cqNzhglLQ5rEODBczpIVxxsHrOUYtDMrsGsyq2NWFAY=.da3b544e-1296-4f6a-afda-29a2e9d3692e@github.com>
Message-ID: <a1DV9XD9bJBTrfI6uosj5RRc4YDsn14-N0ATthAKjLM=.c1df397f-3a45-4ae7-9487-804fd475eb25@github.com>

On Wed, 21 Jan 2026 16:04:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently expect certain files in the legal folder of the jdk image.
>> This should be checked by a test.
>> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check legal dir only for GPL based images

Thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/29272#issuecomment-3783241653

From mbaesken at openjdk.org  Thu Jan 22 08:53:37 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jan 2026 08:53:37 GMT
Subject: Integrated: 8375458: Check legal folder of JDK image for unwanted
 files
In-Reply-To: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
References: <ig4rPlVG0SK_qewwylWyZZlId8j4MyIEQZ4XS47KLTo=.aad85081-ad26-43d6-8fa1-42dd0c9528bd@github.com>
Message-ID: <3K4cxatIbI8UKC9OwD2BxvjzGzjsOOgThU-Eic1ehFU=.8c9d3455-e672-4819-8e48-e4f68af6011e@github.com>

On Fri, 16 Jan 2026 09:13:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently expect certain files in the legal folder of the jdk image.
> This should be checked by a test.
> (recently a check for the bin and lib folders has been added by [JDK-8374471](https://bugs.openjdk.org/browse/JDK-8374471))

This pull request has now been integrated.

Changeset: 6165daf0
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6165daf03c8582cca8e5b075560aa978b90f677c
Stats:     58 lines in 1 file changed: 57 ins; 0 del; 1 mod

8375458: Check legal folder of JDK image for unwanted files

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk/pull/29272

From duke at openjdk.org  Thu Jan 22 10:49:55 2026
From: duke at openjdk.org (David Beaumont)
Date: Thu, 22 Jan 2026 10:49:55 GMT
Subject: RFR: 8375649: idea.sh script adds source paths in a single,
 enormous, line to jdk.iml
In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
Message-ID: <CxdLpDNkx1mALPrhFcK4vSp1VDU57APFJizRpM-Gfrw=.a5cc174e-1b4d-4d83-a75a-ef96944ce764@github.com>

On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow replacement string to contain embedded newlines to split entries.
> This turns output like:
> 
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" /> ... another 10k chars on the end of this line ...
> 
> 
> into:
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" />
>       ... one entry per line ...

The spaces are correct (6) and the first line's indent is in the template file itself.

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

PR Comment: https://git.openjdk.org/jdk/pull/29305#issuecomment-3783728479

From weijun at openjdk.org  Thu Jan 22 12:19:07 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 22 Jan 2026 12:19:07 GMT
Subject: Integrated: 8277489: Rewrite JAAS UnixLoginModule with FFM
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <sSAJoOldLPU2fDE9jz-RiUv1DbEFJqVxYZ06xOnOVgE=.89873aed-4e70-4aeb-906b-22007c0bf731@github.com>

On Fri, 19 Dec 2025 17:56:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Rewrite the native calls with FFM.

This pull request has now been integrated.

Changeset: eda15aa1
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eda15aa19c36142984edaa08850132ca6ae7a369
Stats:     355 lines in 6 files changed: 190 ins; 135 del; 30 mod

8277489: Rewrite JAAS UnixLoginModule with FFM

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: mdoerr, ascarpino, erikj

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

PR: https://git.openjdk.org/jdk/pull/28931

From jwaters at openjdk.org  Thu Jan 22 13:05:23 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jan 2026 13:05:23 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v3]
In-Reply-To: <w0D3uXhXjyrypL1j10wx9TV8Srx-6xax_EgtJwnLwd4=.8b395f6d-66d7-4f1c-a9d8-32bea3b7b8f1@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
 <w0D3uXhXjyrypL1j10wx9TV8Srx-6xax_EgtJwnLwd4=.8b395f6d-66d7-4f1c-a9d8-32bea3b7b8f1@github.com>
Message-ID: <gLOnCtUiGqzbFnGXnYXTSjmT_iuW1sVmYa4JQ2Qu2aM=.dbe6a891-91f6-4ea7-bc5e-b953fa960265@github.com>

On Wed, 21 Jan 2026 18:29:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seems to work as expected:
> 
> ```
> $ du -sh build/linux-x86_64-server-fastdebug/images/jdk/
> 
> # --- Current mainline
> 
> # level=1
> 637M	build/linux-x86_64-server-fastdebug/images/jdk/
> 
> # level=2
> 1.7G	build/linux-x86_64-server-fastdebug/images/jdk/
> 
> # level=3
> 1.8G	build/linux-x86_64-server-fastdebug/images/jdk/
> 
> # default
> 1.7G	build/linux-x86_64-server-fastdebug/images/jdk/
> 
> 
> # --- This PR
> 
> # level=1
> 637M	build/linux-x86_64-server-fastdebug/images/jdk/
> 
> # level=2
> 1.7G	build/linux-x86_64-server-fastdebug/images/jdk/
> 
> # level=3
> 1.8G	build/linux-x86_64-server-fastdebug/images/jdk/
> 
> # default
> 1.7G	build/linux-x86_64-server-fastdebug/images/jdk/
> ```

Thanks! Will integrate tomorrow if no one has any further problems with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/29214#issuecomment-3784300153

From erikj at openjdk.org  Thu Jan 22 17:32:53 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 22 Jan 2026 17:32:53 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v7]
In-Reply-To: <g7GoEkR8QOduHY9T_2Q6haQhnlr4aldkA-NS9t-aRng=.09724780-0e6e-400b-8d39-a334655be54f@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <g7GoEkR8QOduHY9T_2Q6haQhnlr4aldkA-NS9t-aRng=.09724780-0e6e-400b-8d39-a334655be54f@github.com>
Message-ID: <rBlaqfYgkzb7XHRXiOFLBu_3FNoz_lu8mLO214edxD4=.df8ce100-365a-4711-9aac-348417e52a9c@github.com>

On Thu, 22 Jan 2026 02:49:40 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Regenerate testing.html by "make update-build-docs"

doc/testing.html line 634:

> 632: <pre><code>sudo dnf install -y lksctp-tools
> 633: sudo modprobe sctp
> 634: lsmod | grep sctp</code></pre>

This is not what my diff ends up being when running `make update-build-docs`. I get line breaks at <80 chars (don't know exactly, but that's what it looks like). We use pandoc 2.19.2, which version are you using?

Here is the diff when I run `make update-build-docs` in this branch:


diff --git a/doc/testing.html b/doc/testing.html
index 6267df13109..77bd2cfbee0 100644
--- a/doc/testing.html
+++ b/doc/testing.html
@@ -623,12 +623,17 @@ <h3 id="pkcs11-tests">PKCS11 Tests</h3>
 <p>For more notes about the PKCS11 tests, please refer to
 test/jdk/sun/security/pkcs11/README.</p>
 <h3 id="sctp-tests">SCTP Tests</h3>
-<p>The SCTP tests require the SCTP runtime library, which is often not installed by default in popular Linux distributions. Without this library,the SCTP tests will be skipped. If you want to enable the SCTP tests, you should install the SCTP library before running the tests.</p>
-<p>For distributions using the .deb packaging format and the apt tool (such as Debian, Ubuntu, etc.), try this:</p>
+<p>The SCTP tests require the SCTP runtime library, which is often not
+installed by default in popular Linux distributions. Without this
+library,the SCTP tests will be skipped. If you want to enable the SCTP
+tests, you should install the SCTP library before running the tests.</p>
+<p>For distributions using the .deb packaging format and the apt tool
+(such as Debian, Ubuntu, etc.), try this:</p>
 <pre><code>sudo apt install libsctp1
 sudo modprobe sctp
 lsmod | grep sctp</code></pre>
-<p>For distributions using the .rpm packaging format and the dnf tool (such as Fedora, Red Hat, etc.), try this:</p>
+<p>For distributions using the .rpm packaging format and the dnf tool
+(such as Fedora, Red Hat, etc.), try this:</p>
 <pre><code>sudo dnf install -y lksctp-tools
 sudo modprobe sctp
 lsmod | grep sctp</code></pre>

doc/testing.md line 647:

> 645: 
> 646: The SCTP tests require the SCTP runtime library, which is often not installed
> 647: by default in popular Linux distributions. Without this library,the SCTP tests

Suggestion:

by default in popular Linux distributions. Without this library, the SCTP tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2717910363
PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2717122913

From liach at openjdk.org  Thu Jan 22 23:22:23 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jan 2026 23:22:23 GMT
Subject: RFR: 8375649: idea.sh script adds source paths in a single,
 enormous, line to jdk.iml
In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com>
Message-ID: <l2Mn_1u17CwX9sPSO_TjsiC3c0zbAb2G1SaemHwIPH0=.beed3437-9959-44fe-aa1b-2a0b8dada761@github.com>

On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allow replacement string to contain embedded newlines to split entries.
> This turns output like:
> 
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" /> <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" /> ... another 10k chars on the end of this line ...
> 
> 
> into:
> 
>     <content url="file:///home/david/dev/test/jdk">
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/linux/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/open/src/java.base/unix/classes" isTestSource="false" />
>       <sourceFolder url="file:///home/david/dev/test/jdk/closed/src/java.base/share/classes" isTestSource="false" />
>       ... one entry per line ...

Sure, I think someone who revisit that template will notice this bash and update here too :)

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29305#pullrequestreview-3695031056

From syan at openjdk.org  Fri Jan 23 00:32:11 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Jan 2026 00:32:11 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v7]
In-Reply-To: <rBlaqfYgkzb7XHRXiOFLBu_3FNoz_lu8mLO214edxD4=.df8ce100-365a-4711-9aac-348417e52a9c@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <g7GoEkR8QOduHY9T_2Q6haQhnlr4aldkA-NS9t-aRng=.09724780-0e6e-400b-8d39-a334655be54f@github.com>
 <rBlaqfYgkzb7XHRXiOFLBu_3FNoz_lu8mLO214edxD4=.df8ce100-365a-4711-9aac-348417e52a9c@github.com>
Message-ID: <AT4TlWdyQZNPKtzawJ8oUkE9AB1SwKomFtYb-VvRxsk=.ecaa5e08-bfeb-4056-a69c-927d6f1ce91a@github.com>

On Thu, 22 Jan 2026 14:23:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Regenerate testing.html by "make update-build-docs"
>
> doc/testing.md line 647:
> 
>> 645: 
>> 646: The SCTP tests require the SCTP runtime library, which is often not installed
>> 647: by default in popular Linux distributions. Without this library,the SCTP tests
> 
> Suggestion:
> 
> by default in popular Linux distributions. Without this library, the SCTP tests

Sorry....Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2719143368

From syan at openjdk.org  Fri Jan 23 00:48:35 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Jan 2026 00:48:35 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v9]
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <8K0YT7fWdFA1wlMY3oQrWGDUq2c1p5w5XoCf9uO9Sug=.f986bd89-2105-4063-9bd9-113c0f35bef7@github.com>

To protect against unauthorized use of the Oracle email brand, we will be implementing a strict DMARC policy as part of our email security. DMARC (Domain-based Message Authentication, Reporting and Conformance) will help protect against phishing attacks, spam campaigns, and other malicious activities. 

With this implementation, emails sent on behalf of ANY Oracle owned domain will be restricted if they fail DMARC compliance. 

DMARC Info : 
Record= v=DMARC1;p=none;rua=mailto:dmarc_rua at emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf at emaildefense.proofpoint.com;fo=1
Result= none

Questions and more information:

* You may need to take action if you're responsible for email flow from Oracle Cloud, OCI, or acquisition domains. Senders in this category are treated as external emails since they operate outside of Oracle's internal network.

* If you are using the OCI Email Delivery Service, ensure you generate DKIM for your related Header From Domain - refer to https://docs.oracle.com/en-us/iaas/Content/Email/Tasks/configuredkim.htm more info can be found here https://confluence.oraclecorp.com/confluence/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions

* Refer to the DMARC FAQ https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ to learn more about DMARC, if your emails may be affected, and actions you need to take.

* If you have questions, reach out to the #oracle-owned-domains-dmarc Slack channel.

Thank you in advance for your attention to this matter.

> Hi all,
> 
> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.

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

  Use pandoc 2.19.2 to re-generate testing.html

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29320/files
  - new: https://git.openjdk.org/jdk/pull/29320/files/dea937d3..bf392fd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29320&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29320&range=07-08

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

PR: https://git.openjdk.org/jdk/pull/29320

From syan at openjdk.org  Fri Jan 23 00:50:55 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Jan 2026 00:50:55 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v7]
In-Reply-To: <rBlaqfYgkzb7XHRXiOFLBu_3FNoz_lu8mLO214edxD4=.df8ce100-365a-4711-9aac-348417e52a9c@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <g7GoEkR8QOduHY9T_2Q6haQhnlr4aldkA-NS9t-aRng=.09724780-0e6e-400b-8d39-a334655be54f@github.com>
 <rBlaqfYgkzb7XHRXiOFLBu_3FNoz_lu8mLO214edxD4=.df8ce100-365a-4711-9aac-348417e52a9c@github.com>
Message-ID: <fX0FK34Z7bV0aIkRbkB7Tsa5urF0nODMj8PC5qNQ_Rc=.46b69b00-1a94-4a2f-a240-1f1498d38fb1@github.com>

To protect against unauthorized use of the Oracle email brand, we will be implementing a strict DMARC policy as part of our email security. DMARC (Domain-based Message Authentication, Reporting and Conformance) will help protect against phishing attacks, spam campaigns, and other malicious activities. 

With this implementation, emails sent on behalf of ANY Oracle owned domain will be restricted if they fail DMARC compliance. 

DMARC Info : 
Record= v=DMARC1;p=none;rua=mailto:dmarc_rua at emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf at emaildefense.proofpoint.com;fo=1
Result= none

Questions and more information:

* You may need to take action if you're responsible for email flow from Oracle Cloud, OCI, or acquisition domains. Senders in this category are treated as external emails since they operate outside of Oracle's internal network.

* If you are using the OCI Email Delivery Service, ensure you generate DKIM for your related Header From Domain - refer to https://docs.oracle.com/en-us/iaas/Content/Email/Tasks/configuredkim.htm more info can be found here https://confluence.oraclecorp.com/confluence/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions

* Refer to the DMARC FAQ https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ to learn more about DMARC, if your emails may be affected, and actions you need to take.

* If you have questions, reach out to the #oracle-owned-domains-dmarc Slack channel.

Thank you in advance for your attention to this matter.

On Thu, 22 Jan 2026 17:29:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Regenerate testing.html by "make update-build-docs"
>
> doc/testing.html line 634:
> 
>> 632: <pre><code>sudo dnf install -y lksctp-tools
>> 633: sudo modprobe sctp
>> 634: lsmod | grep sctp</code></pre>
> 
> This is not what my diff ends up being when running `make update-build-docs`. I get line breaks at <80 chars (don't know exactly, but that's what it looks like). We use pandoc 2.19.2, which version are you using?
> 
> Here is the diff when I run `make update-build-docs` in this branch:
> 
> 
> diff --git a/doc/testing.html b/doc/testing.html
> index 6267df13109..77bd2cfbee0 100644
> --- a/doc/testing.html
> +++ b/doc/testing.html
> @@ -623,12 +623,17 @@ <h3 id="pkcs11-tests">PKCS11 Tests</h3>
>  <p>For more notes about the PKCS11 tests, please refer to
>  test/jdk/sun/security/pkcs11/README.</p>
>  <h3 id="sctp-tests">SCTP Tests</h3>
> -<p>The SCTP tests require the SCTP runtime library, which is often not installed by default in popular Linux distributions. Without this library,the SCTP tests will be skipped. If you want to enable the SCTP tests, you should install the SCTP library before running the tests.</p>
> -<p>For distributions using the .deb packaging format and the apt tool (such as Debian, Ubuntu, etc.), try this:</p>
> +<p>The SCTP tests require the SCTP runtime library, which is often not
> +installed by default in popular Linux distributions. Without this
> +library,the SCTP tests will be skipped. If you want to enable the SCTP
> +tests, you should install the SCTP library before running the tests.</p>
> +<p>For distributions using the .deb packaging format and the apt tool
> +(such as Debian, Ubuntu, etc.), try this:</p>
>  <pre><code>sudo apt install libsctp1
>  sudo modprobe sctp
>  lsmod | grep sctp</code></pre>
> -<p>For distributions using the .rpm packaging format and the dnf tool (such as Fedora, Red Hat, etc.), try this:</p>
> +<p>For distributions using the .rpm packaging format and the dnf tool
> +(such as Fedora, Red Hat, etc.), try this:</p>
>  <pre><code>sudo dnf install -y lksctp-tools
>  sudo modprobe sctp
>  lsmod | grep sctp</code></pre>

Sorry, I missed the configure warning about pandoc version. I used pandoc 2.9.2.1 from ubuntu22.

I have updated pandoc to 2.19.2 and re-generate testing.html.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29320#discussion_r2719178651

From syan at openjdk.org  Fri Jan 23 00:32:09 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Jan 2026 00:32:09 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v8]
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <QD53rQdp22si1Wy6ytGgv5NM8e8_fpICyixkwqeNOZQ=.352932f5-3ea1-4193-a5e9-89e9cf50ca00@github.com>

> Hi all,
> 
> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.

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

  Add a whitespace after comma
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29320/files
  - new: https://git.openjdk.org/jdk/pull/29320/files/4fc0f17f..dea937d3

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

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

PR: https://git.openjdk.org/jdk/pull/29320

From jwaters at openjdk.org  Fri Jan 23 07:10:37 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jan 2026 07:10:37 GMT
Subject: RFR: 8375241: Simplify --with-native-debug-symbols-level option
 implementation [v3]
In-Reply-To: <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
 <AIUwL2dGeEpVucIGgTXpN5kv0-zcw2Gh7_rJgpfYL4Q=.3cfc2992-3951-4060-8b3f-63b1eb0dee2d@github.com>
Message-ID: <tMIOI7-xJdsoaVuMFBhXLRK6BhzD0Ln5cxI6elphQqk=.2838664a-d173-4772-8fa7-c69a54344578@github.com>

On Wed, 21 Jan 2026 06:24:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use auto for default in flags-cflags.m4

I'll take it that everyone's fine with this then. Thanks for the reviews Aleksey and Erik!

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

PR Comment: https://git.openjdk.org/jdk/pull/29214#issuecomment-3788657864

From jwaters at openjdk.org  Fri Jan 23 07:10:38 2026
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jan 2026 07:10:38 GMT
Subject: Integrated: 8375241: Simplify --with-native-debug-symbols-level option
 implementation
In-Reply-To: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
References: <qAidO_bbEn2Rf5ubobkZrvzdW70gdmmv8A87YLyrjDQ=.d248b581-74f2-4e5e-8495-06e02c5a1873@github.com>
Message-ID: <i6n1dgj4lZKJnjhEN9Y8QSGg8r9pjA9VSW8Eld_l55A=.aeadba64-13e1-47a0-a607-582fe5cb5e47@github.com>

On Wed, 14 Jan 2026 03:01:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> --with-native-debug-symbols-level was added some time ago to allow selecting the level of debugging information created for compiled binaries. The UTIL_ARG_WITH utility that the option implementation uses has several features that can be used to simplify handling of this option, so that is done in this change.

This pull request has now been integrated.

Changeset: 39f0e6d6
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39f0e6d6f91bf7e75862851ca0e00fc62780f938
Stats:     23 lines in 1 file changed: 4 ins; 8 del; 11 mod

8375241: Simplify --with-native-debug-symbols-level option implementation

Reviewed-by: erikj, shade

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

PR: https://git.openjdk.org/jdk/pull/29214

From jlahoda at openjdk.org  Fri Jan 23 12:15:35 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 23 Jan 2026 12:15:35 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v12]
In-Reply-To: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
Message-ID: <DKE6Pbb09TIk8nGp1U2LuQIeK9lawosdOiwPMQMVli4=.5183fb43-2484-458f-8a0d-7b419c71fddd@github.com>

> Consider code like:
> 
> package test;
> public class Test {
>     private int test(Root r) {
>         return switch (r) {
>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>         };
>     }
>     sealed interface Base {}
>     record R1() implements Base {}
>     record R2(Base b1) implements Base {}
>     record Root(R2 b2, R2 b3) {}
> }
> ``` 
> 
> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
> 
> $ javac test/Test.java
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
> 1 error
> 
> 
> The goal of this PR is to improve the error, at least in some cases to something along these lines:
> 
> $ javac test/Test.java 
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
>   missing patterns:
>       Root(R2(R2 _), R2(R2 _))
> 1 error
> 
> 
> The (very simplified) way it works in a recursive (or induction) way:
> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
> - for a current missing pattern, try to enhance it:
>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
> 
> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
> 
> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
> 
> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
> 
> There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:

 - Avoiding repeated code as suggested.
 - Merge remote-tracking branch 'upstream/master' into JDK-8367530
 - Fixing test.
 - Merge branch 'master' into JDK-8367530-3
 - Reflecting review feedback: using multi-line diagnostics; passing PatternDescriptions through the diagnostics to format it at the end.
 - Fixing cases that are based on review feedback.
 - Merge branch 'master' into JDK-8367530
 - Fixing trailing whitespaces.
 - Cleanup, reflecting review feedback.
 - Apply suggestions from code review
   
   Co-authored-by: Aggelos Biboudis <biboudis at gmail.com>
 - ... and 39 more: https://git.openjdk.org/jdk/compare/6f6966b2...e41e7268

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

Changes: https://git.openjdk.org/jdk/pull/27256/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=11
  Stats: 1467 lines in 19 files changed: 1369 ins; 50 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/27256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27256/head:pull/27256

PR: https://git.openjdk.org/jdk/pull/27256

From jlahoda at openjdk.org  Fri Jan 23 16:23:20 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 23 Jan 2026 16:23:20 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
Message-ID: <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>

> Consider code like:
> 
> package test;
> public class Test {
>     private int test(Root r) {
>         return switch (r) {
>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>         };
>     }
>     sealed interface Base {}
>     record R1() implements Base {}
>     record R2(Base b1) implements Base {}
>     record Root(R2 b2, R2 b3) {}
> }
> ``` 
> 
> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
> 
> $ javac test/Test.java
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
> 1 error
> 
> 
> The goal of this PR is to improve the error, at least in some cases to something along these lines:
> 
> $ javac test/Test.java 
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
>   missing patterns:
>       Root(R2(R2 _), R2(R2 _))
> 1 error
> 
> 
> The (very simplified) way it works in a recursive (or induction) way:
> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
> - for a current missing pattern, try to enhance it:
>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
> 
> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
> 
> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
> 
> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
> 
> There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27256/files
  - new: https://git.openjdk.org/jdk/pull/27256/files/e41e7268..8f1ea6b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=11-12

  Stats: 23 lines in 3 files changed: 0 ins; 2 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27256/head:pull/27256

PR: https://git.openjdk.org/jdk/pull/27256

From erikj at openjdk.org  Fri Jan 23 18:01:02 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Jan 2026 18:01:02 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v9]
In-Reply-To: <8K0YT7fWdFA1wlMY3oQrWGDUq2c1p5w5XoCf9uO9Sug=.f986bd89-2105-4063-9bd9-113c0f35bef7@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <8K0YT7fWdFA1wlMY3oQrWGDUq2c1p5w5XoCf9uO9Sug=.f986bd89-2105-4063-9bd9-113c0f35bef7@github.com>
Message-ID: <50EV4e3HUZVEzScyRxmZ90MMNBKN6RIBJCCLZh2joUM=.f5df3d26-ac12-405a-b744-e051ceb5fca0@github.com>

On Fri, 23 Jan 2026 00:48:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use pandoc 2.19.2 to re-generate testing.html

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29320#pullrequestreview-3698849034

From liach at openjdk.org  Fri Jan 23 18:26:09 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Jan 2026 18:26:09 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v12]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <FH9LLahTQwV2ooiNW4LOJbS705zM-gl9iybsWCPWOak=.d23925c7-12e8-403e-bc15-5de9bf9396d8@github.com>

> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH.  Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`)

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 23 additional commits since the last revision:

 - Design detail updates, thanks to jorn
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - Missed IR test review, rearrange benches
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - Stage
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - Review
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - Bugs and verify loader leak
 - Try to avoid loader leak
 - ... and 13 more: https://git.openjdk.org/jdk/compare/4ac48240...77ea5565

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/1d5461db..77ea5565

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=10-11

  Stats: 93166 lines in 3834 files changed: 46542 ins; 16001 del; 30623 mod
  Patch: https://git.openjdk.org/jdk/pull/28585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585

PR: https://git.openjdk.org/jdk/pull/28585

From jvernee at openjdk.org  Fri Jan 23 19:22:03 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 23 Jan 2026 19:22:03 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v12]
In-Reply-To: <FH9LLahTQwV2ooiNW4LOJbS705zM-gl9iybsWCPWOak=.d23925c7-12e8-403e-bc15-5de9bf9396d8@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <FH9LLahTQwV2ooiNW4LOJbS705zM-gl9iybsWCPWOak=.d23925c7-12e8-403e-bc15-5de9bf9396d8@github.com>
Message-ID: <B_-eCm7Ny16kkWuePrk80GuCNHUAHdm-BPCeV_I_f8c=.a719acc2-cef1-4fad-a61f-0ca4cb06be21@github.com>

On Fri, 23 Jan 2026 18:26:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH.  Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`)
>
> 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 23 additional commits since the last revision:
> 
>  - Design detail updates, thanks to jorn
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Missed IR test review, rearrange benches
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Stage
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Review
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Bugs and verify loader leak
>  - Try to avoid loader leak
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/d8405cdd...77ea5565

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2043:

> 2041:         //
> 2042:         // Condition 1 and 2 indicates this access descriptor may see a VarHandle
> 2043:         // different from the captured VarHandle.  Condition 3 requires the

Suggestion:

        // Condition 1 and 2 indicates this access descriptor may see a VarHandle
        // different from the captured VarHandle.


I don't see how this follows from condition 1 and 2 holding. A failure in either condition means we are may see multiple VH instance. I suggest:

Suggestion:

        // If either condition 1 or 2 doesn't hold, we may see different var handle instances using the
        // same shared AccessDescriptor. In those cases we only cache the adaptation for one of the
        // var handle instances (the first one). Other instances will always use the slow path.

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2049:

> 2047:         // such as compareAndSet can appear at two sites, where each site
> 2048:         // has its own constant VarHandle. Such a usage pattern hurts adaption,
> 2049:         // but is perfectly dealt by the getMethodType_V constant folding branch.

I think this information should be put on the template string instead, since it's mostly referencing that code. I think it's enough to say that we 'skip potentially costly adaptation' by going through the `getMethodType_V` branch.

>From the text as written, it's not clear why such usage patterns hurt adaptation. I think It would be more accurate to say that: "in such cases, only one of the two var handles will have its adaptation cached".

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2055:

> 2053:         // invocation type of the underlying MemberName, or MH for indirect VH),
> 2054:         // perform a foldable lookup with a hash table, and hope C2 inline it
> 2055:         // all. Such an optimization applies for general MethodHandle.asType.

Suggestion:

        // all. Such an optimization applies to general MethodHandle.asType.

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2055:

> 2053:         // invocation type of the underlying MemberName, or MH for indirect VH),
> 2054:         // perform a foldable lookup with a hash table, and hope C2 inline it
> 2055:         // all. Such an optimization applies for general MethodHandle.asType.

This reads as "put a ... to another ... perform", which doesn't sounds grammatically correct.

Maybe:
Suggestion:

        // In the long run, we wish to cache each specific-type invoker that converts
        // from one fixed type (symbolicMethodTypeInvoker) to another (the
        // invocation type of the underlying MemberName, or MH for indirect VH),
        // using a foldable lookup with a hash table, and hope C2 inline it
        // all. Such an optimization applies for general MethodHandle.asType.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722389574
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722416361
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722376203
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722514070

From liach at openjdk.org  Fri Jan 23 20:08:58 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Jan 2026 20:08:58 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v13]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>

> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH.  Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`)

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

  Wording update, thanks Jorn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/77ea5565..5ba75d45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=11-12

  Stats: 16 lines in 2 files changed: 1 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585

PR: https://git.openjdk.org/jdk/pull/28585

From jrose at openjdk.org  Fri Jan 23 22:13:18 2026
From: jrose at openjdk.org (John R Rose)
Date: Fri, 23 Jan 2026 22:13:18 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v13]
In-Reply-To: <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
Message-ID: <uHnPluToR2CpdEHVxFsb0u7PkU96ow9eScN6PR9tUuo=.02f695cd-7cd4-4517-9d28-6626538ceb19@github.com>

On Fri, 23 Jan 2026 20:08:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH.  Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`)
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording update, thanks Jorn

make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 130:

> 128: 
> 129:     // The void bypass is necessary if a (name + return-dropping type) combination has multiple call sites, each
> 130:     // having its own constant VarHandle. In that case, the AccessMode::adaptedMethodHandle adaption mechanism

wrong word:  s/adaption/adaptation/

https://grammarist.com/usage/adaption-adaptation/

(Wiktionary implies they are the same, but they apply to different areas of discourse.  The grammarist article indicates that "adaptation" is the more correct word here.  Also, the word "adaption" seems to be mostly obsolete.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723023261

From jrose at openjdk.org  Fri Jan 23 23:05:30 2026
From: jrose at openjdk.org (John R Rose)
Date: Fri, 23 Jan 2026 23:05:30 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v13]
In-Reply-To: <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
Message-ID: <kr-zeuOunrUSwxZgULGX3I0-9wnMZqYHqkhKXjroG2o=.fa269f1f-0c06-4a15-8680-d87a23a70729@github.com>

On Fri, 23 Jan 2026 20:08:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH.  Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`)
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording update, thanks Jorn

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2022:

> 2020:     // In a class file, the JVM creates one access descriptor for one (name, type) combination.
> 2021:     // Many call sites in one class can have the same (name, type) combination.
> 2022:     // In this case, they share the same access descriptor.

I love it when, as part of maintenance, informative comments like these are added.  Thanks!

Please add a comment something like this as well:


// Note:  The integers type and mode are proxies for the AccessType and
// AccessMode enumerations, and the access type simply summarizes something
// about the shape of the access mode.  The crucial type here, of the (name, type)
// combination, is the MethodType that decorates the access shape with specific
// strong types for the handle operation inputs and outputs.


I think it was a small faux pas, some time ago, to choose the term `AccessType` instead of `AccessKind`, simply because the term "type" is already disastrously overloaded in our system.  But that?s water under the bridge.  Now we have one more "type" floating around in this neighborhood.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723131985

From jrose at openjdk.org  Sat Jan 24 01:16:48 2026
From: jrose at openjdk.org (John R Rose)
Date: Sat, 24 Jan 2026 01:16:48 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v13]
In-Reply-To: <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
Message-ID: <QFQfSl7VvHt-8r5axFpFsj73CZOlhpuK0q121C1yR3M=.c84f42b2-c549-462c-b9a5-9cb4f694fcd1@github.com>

On Fri, 23 Jan 2026 20:08:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH.  Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`)
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording update, thanks Jorn

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2014:

> 2012:     // Exists for the adaption mechanism of AccessDescriptor
> 2013:     // Each VH should report its explicitly (receiver, coordinates) and
> 2014:     // implicitly (static declaring class) used class to MethodHandle.isReachableFrom

Perhaps add a comment:  "Classes which define this abstract method should themselves be final or locally sealed, to make it possible to ensure that all relevant classes are taken into account."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723365226

From jrose at openjdk.org  Sat Jan 24 01:21:04 2026
From: jrose at openjdk.org (John R Rose)
Date: Sat, 24 Jan 2026 01:21:04 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v13]
In-Reply-To: <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
Message-ID: <X31lIIu3LX5q1q-5w9jZX3H1x5F6Lifbbqp1sHfMKNs=.77570e15-0dab-4fbe-9d2d-8ce716d89b46@github.com>

On Fri, 23 Jan 2026 20:08:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH.  Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`)
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording update, thanks Jorn

Good work.  I?m assuming you will address my previous comments.

src/java.base/share/classes/java/lang/invoke/SegmentVarHandle.java line 69:

> 67:     @Override
> 68:     boolean isReachableFrom(ClassLoader cl) {
> 69:         return true;

Give a comment explaining why this is correct.  Something like:  The segment is neither an instance nor an array, so it is effectively common to all class loaders.  Compare this to a class on the boot class loader, which also uses only types that are common reachable from all other class loaders.  (Or something like that.)

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

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3700343726
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723372435

From syan at openjdk.org  Sun Jan 25 01:12:08 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 25 Jan 2026 01:12:08 GMT
Subject: RFR: 8375683: Add notes for sctp tests [v5]
In-Reply-To: <x0GUaT2HK2Nv0qE0PXfdJw6gkzsp7vskRf2WkyCL3RI=.2c5dfc77-9ab7-48dd-b4f2-23cce8482720@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
 <3t1XwCMiwJ_XXoMOzKLwUOpYPRxy2uG8rtv4UKjinBQ=.7ce53b48-a35d-4417-a3a9-23bcb9a17f04@github.com>
 <x0GUaT2HK2Nv0qE0PXfdJw6gkzsp7vskRf2WkyCL3RI=.2c5dfc77-9ab7-48dd-b4f2-23cce8482720@github.com>
Message-ID: <GOeyaKrx5peUSRbL4pFJXQq-tTOE5V0WgXoJThSihwU=.20a5b7e9-047a-479b-bb49-b28b48e86f81@github.com>

On Wed, 21 Jan 2026 08:12:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. Update apt/dnf description; 2. Add "sudo modprobe sctp" after apt install
>
> Marked as reviewed by vyazici (Committer).

Thanks fpr the patient reviews and suggestions @vy @erikj79.

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

PR Comment: https://git.openjdk.org/jdk/pull/29320#issuecomment-3795787809

From syan at openjdk.org  Sun Jan 25 01:12:09 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 25 Jan 2026 01:12:09 GMT
Subject: Integrated: 8375683: Add notes for sctp tests
In-Reply-To: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
References: <wkEKT-W6YQIy-KK-795rX6ZqEeVKcd8DK6l0Y17nYX4=.bbdea9c9-9d24-4286-9094-ea202e0a1be5@github.com>
Message-ID: <eokPviq3cl3MIL1f8lvYb-LxYstut1kd1ffbjCMLCzE=.15b1060f-12cc-4a4d-aeb9-37f955b851a4@github.com>

On Tue, 20 Jan 2026 13:16:22 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The sctp tests need libsctp.so.1 to be installed, otherwise those tests will report skipped. Seems that there is no help information to descript how to run those tests. I think it's meaningful to add help information how to run those tests.

This pull request has now been integrated.

Changeset: 93255602
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/932556026d6d49fe6f74d4ec4afcb72448611766
Stats:     42 lines in 2 files changed: 42 ins; 0 del; 0 mod

8375683: Add notes for sctp tests

Reviewed-by: erikj, vyazici

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

PR: https://git.openjdk.org/jdk/pull/29320

From syan at openjdk.org  Sun Jan 25 01:22:32 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 25 Jan 2026 01:22:32 GMT
Subject: [jdk26] RFR: 8375683: Add notes for sctp tests
Message-ID: <M1WePzp_OgGbHolh-dAdR4cu2E7EQpZAVKaHwLeccCc=.d87daf0f-bef3-4525-9193-63814167ab1f@github.com>

Hi all,

This pull request contains a backport of commit [93255602](https://github.com/openjdk/jdk/commit/932556026d6d49fe6f74d4ec4afcb72448611766) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk26 branch.

The commit being backported is add the descriptions about hwo to running the SCTP tests. Only touch the testing.md/testing/html.

Thanks!

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

Commit messages:
 - Backport 932556026d6d49fe6f74d4ec4afcb72448611766

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

PR: https://git.openjdk.org/jdk/pull/29399

From liach at openjdk.org  Sun Jan 25 19:13:05 2026
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jan 2026 19:13:05 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement
Message-ID: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>

We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:


@jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions


Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.

As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.

I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!

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

Commit messages:
 - 8376274: JSpec preview support and output enhancement

Changes: https://git.openjdk.org/jdk/pull/29402/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29402&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376274
  Stats: 50 lines in 2 files changed: 34 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/29402.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29402/head:pull/29402

PR: https://git.openjdk.org/jdk/pull/29402

From wanghaomin at openjdk.org  Mon Jan 26 02:37:30 2026
From: wanghaomin at openjdk.org (Wang Haomin)
Date: Mon, 26 Jan 2026 02:37:30 GMT
Subject: RFR: 8376276: Add javafx to allowed-list of CheckFiles
Message-ID: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>

...
  visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx-swt.jar
  --> ERROR this file is not allowed:javafx-swt.jar
...
  visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx.properties
  --> ERROR this file is not allowed:javafx.properties
...
----------System.err:(10/494)----------
java.lang.Error: lib dir scan failed
	at CheckFiles.main(CheckFiles.java:122)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1516)


Just add javafx to allowed-list.

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

Commit messages:
 - 8376276: Add javafx to allowed-list of CheckFiles

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

PR: https://git.openjdk.org/jdk/pull/29403

From mcimadamore at openjdk.org  Mon Jan 26 11:52:16 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 11:52:16 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
Message-ID: <kUGppMQMVPS6xeWpiRLsQSNmd4fEnH3BSiOSHb6tcf0=.f54b8a2e-f305-474e-b025-7ad895d60bd8@github.com>

On Fri, 23 Jan 2026 16:23:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 771:

> 769:                     exhaustivenessResult.notExhaustiveDetails()
> 770:                                        .stream()
> 771:                                        .sorted((pd1, pd2) -> pd1.toString().compareTo(pd2.toString()))

Maybe we could have pattern descriptions be comparable?

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 43:

> 41: # option name       the name of a command line option
> 42: # path              a path
> 43: # patter            a pattern/pattern description

Suggestion:

# pattern            a pattern/pattern description

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727309680
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727310628

From mcimadamore at openjdk.org  Mon Jan 26 11:57:22 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 11:57:22 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
Message-ID: <sci1FRa4wDhZ9QTBFHMBDvAcyLG32H6c1pVzuBG3cWg=.6db14001-ad13-4d9d-97c4-f14f4a2df976@github.com>

On Fri, 23 Jan 2026 16:23:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java line 237:

> 235:                                                   StringUtils.toLowerCase(tag.name()));
> 236:         }
> 237:         else if (arg instanceof BindingPattern bp) {

Have you tried playing with the Formattable interface? This is used by diagnostic formatters as an escape hatch to provide custom formatting -- but probably that's not good enough, as Formattable expects to just map an object into a string w/o the help of a formatter -- which is clearly not the case here. Maybe just having an abstract `String format(AbstractDiagnosticFormatter)` in PatternDescription could be enough -- then the code here doesn't have to worry about all possible cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727324700

From mcimadamore at openjdk.org  Mon Jan 26 12:02:55 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 12:02:55 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <ko8G3gAmJ492gUOCSDNhFzkrdcDZ2msQ-1Ibd8RgZ_Y=.676dbbe4-3cc1-45ab-8f34-177086f116ee@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <sci1FRa4wDhZ9QTBFHMBDvAcyLG32H6c1pVzuBG3cWg=.6db14001-ad13-4d9d-97c4-f14f4a2df976@github.com>
 <ko8G3gAmJ492gUOCSDNhFzkrdcDZ2msQ-1Ibd8RgZ_Y=.676dbbe4-3cc1-45ab-8f34-177086f116ee@github.com>
Message-ID: <1MCPn8qLXtQCTcILUi0FH21LnRRTGkgYxDKD9neBhIs=.401b342d-c71e-4710-af87-e8b288c22fd0@github.com>

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

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java line 237:
>> 
>>> 235:                                                   StringUtils.toLowerCase(tag.name()));
>>> 236:         }
>>> 237:         else if (arg instanceof BindingPattern bp) {
>> 
>> Have you tried playing with the Formattable interface? This is used by diagnostic formatters as an escape hatch to provide custom formatting -- but probably that's not good enough, as Formattable expects to just map an object into a string w/o the help of a formatter -- which is clearly not the case here. Maybe just having an abstract `String format(AbstractDiagnosticFormatter)` in PatternDescription could be enough -- then the code here doesn't have to worry about all possible cases.
>
> That said, in Rich formatter we also need to preprocess, so perhaps keeping the code as is here would be more symmetric...

I suppose overall I'm not entirely sure if, at this point, pattern descriptions should be pattern descriptions, or already translated into some kind of fragment -- because the code in formatters can deal with fragments recursively very well -- but can do less so with objects.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727338487

From mcimadamore at openjdk.org  Mon Jan 26 12:02:57 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 12:02:57 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
Message-ID: <MnLpxtShPvGATnGQosXhEoqHdD8iTmjo4QxQAJi5b-8=.479c503e-c50d-4ae0-a864-5e8917c10dbb@github.com>

On Fri, 23 Jan 2026 16:23:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java line 215:

> 213:      */
> 214:     protected void preprocessArgument(Object arg) {
> 215:         //TODO: preprocess for patterns

Is this comment this valid?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727332637

From mcimadamore at openjdk.org  Mon Jan 26 12:02:54 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 12:02:54 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <sci1FRa4wDhZ9QTBFHMBDvAcyLG32H6c1pVzuBG3cWg=.6db14001-ad13-4d9d-97c4-f14f4a2df976@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <sci1FRa4wDhZ9QTBFHMBDvAcyLG32H6c1pVzuBG3cWg=.6db14001-ad13-4d9d-97c4-f14f4a2df976@github.com>
Message-ID: <ko8G3gAmJ492gUOCSDNhFzkrdcDZ2msQ-1Ibd8RgZ_Y=.676dbbe4-3cc1-45ab-8f34-177086f116ee@github.com>

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

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java line 237:
> 
>> 235:                                                   StringUtils.toLowerCase(tag.name()));
>> 236:         }
>> 237:         else if (arg instanceof BindingPattern bp) {
> 
> Have you tried playing with the Formattable interface? This is used by diagnostic formatters as an escape hatch to provide custom formatting -- but probably that's not good enough, as Formattable expects to just map an object into a string w/o the help of a formatter -- which is clearly not the case here. Maybe just having an abstract `String format(AbstractDiagnosticFormatter)` in PatternDescription could be enough -- then the code here doesn't have to worry about all possible cases.

That said, in Rich formatter we also need to preprocess, so perhaps keeping the code as is here would be more symmetric...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727333566

From mcimadamore at openjdk.org  Mon Jan 26 12:16:27 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 12:16:27 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
Message-ID: <w7W5OfAbXv10mMiwTUkQj6gGlY2TXVQ_uoRNqlR7-50=.35de3b38-4059-4d35-8710-9d76bb46dab7@github.com>

On Fri, 23 Jan 2026 16:23:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 691:

> 689:     }
> 690: 
> 691:     protected void checkTimeout() {

This is probably no longer a good name for this method.

More seriously, I have a question as to why this method is only checked (AFAICS) from `isBpCovered`. I would have expected it to be more directly tied to `computeMissingPatternDescriptions` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727369769

From mcimadamore at openjdk.org  Mon Jan 26 12:16:29 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 12:16:29 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <w7W5OfAbXv10mMiwTUkQj6gGlY2TXVQ_uoRNqlR7-50=.35de3b38-4059-4d35-8710-9d76bb46dab7@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <w7W5OfAbXv10mMiwTUkQj6gGlY2TXVQ_uoRNqlR7-50=.35de3b38-4059-4d35-8710-9d76bb46dab7@github.com>
Message-ID: <65Rgv2InuhjHS1sWTQhXtw-ihBy5N4vi-llhZKNDch0=.47cc956d-df60-4db6-a9d8-21c0974c6ed6@github.com>

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

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 691:
> 
>> 689:     }
>> 690: 
>> 691:     protected void checkTimeout() {
> 
> This is probably no longer a good name for this method.
> 
> More seriously, I have a question as to why this method is only checked (AFAICS) from `isBpCovered`. I would have expected it to be more directly tied to `computeMissingPatternDescriptions` ?

Maybe the intent is that you don't want to just check the "depth" of the check, but also the "width" -- e.g. if there's few nested record patterns, but each has a huge number of components.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727375413

From mcimadamore at openjdk.org  Mon Jan 26 12:20:50 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 12:20:50 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <65Rgv2InuhjHS1sWTQhXtw-ihBy5N4vi-llhZKNDch0=.47cc956d-df60-4db6-a9d8-21c0974c6ed6@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <w7W5OfAbXv10mMiwTUkQj6gGlY2TXVQ_uoRNqlR7-50=.35de3b38-4059-4d35-8710-9d76bb46dab7@github.com>
 <65Rgv2InuhjHS1sWTQhXtw-ihBy5N4vi-llhZKNDch0=.47cc956d-df60-4db6-a9d8-21c0974c6ed6@github.com>
Message-ID: <xWGy332zK_nQJNWboJR9TsCPm15gdOFn7ioiN0fGVVU=.b710510d-e7ad-4afc-8a9d-cf1f449f6407@github.com>

On Mon, 26 Jan 2026 12:13:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 691:
>> 
>>> 689:     }
>>> 690: 
>>> 691:     protected void checkTimeout() {
>> 
>> This is probably no longer a good name for this method.
>> 
>> More seriously, I have a question as to why this method is only checked (AFAICS) from `isBpCovered`. I would have expected it to be more directly tied to `computeMissingPatternDescriptions` ?
>
> Maybe the intent is that you don't want to just check the "depth" of the check, but also the "width" -- e.g. if there's few nested record patterns, but each has a huge number of components.

Also, `isBpCovered` seems to be called by routines (like `reduceRecordPattern`) that do not seem related to the new logic (which is what got me suspicious about the location of the update to begin with). Which has (at least in theory) potential for `TooManyChecksException` to trigger in places where it's not expected? (but maybe that's handled by the special value `-1` which is carefully set after the new logic runs)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727385802

From mcimadamore at openjdk.org  Mon Jan 26 12:24:49 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 12:24:49 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <xWGy332zK_nQJNWboJR9TsCPm15gdOFn7ioiN0fGVVU=.b710510d-e7ad-4afc-8a9d-cf1f449f6407@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <w7W5OfAbXv10mMiwTUkQj6gGlY2TXVQ_uoRNqlR7-50=.35de3b38-4059-4d35-8710-9d76bb46dab7@github.com>
 <65Rgv2InuhjHS1sWTQhXtw-ihBy5N4vi-llhZKNDch0=.47cc956d-df60-4db6-a9d8-21c0974c6ed6@github.com>
 <xWGy332zK_nQJNWboJR9TsCPm15gdOFn7ioiN0fGVVU=.b710510d-e7ad-4afc-8a9d-cf1f449f6407@github.com>
Message-ID: <m99SqXYs7kBO5NANDfh87PLcHEEDvre2Nc7RRLGNr5s=.1d96e254-1d92-49e1-9efe-a74ebc5eca0c@github.com>

On Mon, 26 Jan 2026 12:17:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maybe the intent is that you don't want to just check the "depth" of the check, but also the "width" -- e.g. if there's few nested record patterns, but each has a huge number of components.
>
> Also, `isBpCovered` seems to be called by routines (like `reduceRecordPattern`) that do not seem related to the new logic (which is what got me suspicious about the location of the update to begin with). Which has (at least in theory) potential for `TooManyChecksException` to trigger in places where it's not expected? (but maybe that's handled by the special value `-1` which is carefully set after the new logic runs)

A possible suggestion might be to add this check inside `doExpandMissingPatternDescriptions` -- after the `if (toExpand instanceof BindingPattern bp) {` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2727399031

From erikj at openjdk.org  Mon Jan 26 14:15:31 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Jan 2026 14:15:31 GMT
Subject: [jdk26] RFR: 8375683: Add notes for sctp tests
In-Reply-To: <M1WePzp_OgGbHolh-dAdR4cu2E7EQpZAVKaHwLeccCc=.d87daf0f-bef3-4525-9193-63814167ab1f@github.com>
References: <M1WePzp_OgGbHolh-dAdR4cu2E7EQpZAVKaHwLeccCc=.d87daf0f-bef3-4525-9193-63814167ab1f@github.com>
Message-ID: <Gqqirw86pYN-NfGqou54RDU4aNa5GSKGTKI4IA0oJNo=.b742600f-abaa-40a1-8672-50c666095ab8@github.com>

On Sun, 25 Jan 2026 01:15:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [93255602](https://github.com/openjdk/jdk/commit/932556026d6d49fe6f74d4ec4afcb72448611766) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk26 branch.
> 
> The commit being backported is add the descriptions about hwo to running the SCTP tests. Only touch the testing.md/testing/html.
> 
> Thanks!

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29399#pullrequestreview-3706224753

From erikj at openjdk.org  Mon Jan 26 14:16:47 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Jan 2026 14:16:47 GMT
Subject: RFR: 8376276: Add javafx to allowed-list of CheckFiles
In-Reply-To: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
References: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
Message-ID: <4FnM252oA3fJwCWau74uzaiFEeaY4dNL4pGFjOwvpY0=.e94ebe95-1986-4517-a2dd-214a8a9aa7f8@github.com>

On Mon, 26 Jan 2026 02:31:11 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> ...
>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx-swt.jar
>   --> ERROR this file is not allowed:javafx-swt.jar
> ...
>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx.properties
>   --> ERROR this file is not allowed:javafx.properties
> ...
> ----------System.err:(10/494)----------
> java.lang.Error: lib dir scan failed
> 	at CheckFiles.main(CheckFiles.java:122)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> 	at java.base/java.lang.Thread.run(Thread.java:1516)
> 
> 
> Just add javafx to allowed-list.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29403#pullrequestreview-3706232343

From kcr at openjdk.org  Mon Jan 26 16:55:40 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 26 Jan 2026 16:55:40 GMT
Subject: RFR: 8376276: Add javafx to allowed-list of CheckFiles
In-Reply-To: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
References: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
Message-ID: <rtxB2qpT54mEVylMu0p0uUEKWsJgdBamtRF0D7deMs0=.05c36bb6-b9c5-4ac4-89fc-b1226d32cc3b@github.com>

On Mon, 26 Jan 2026 02:31:11 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> ...
>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx-swt.jar
>   --> ERROR this file is not allowed:javafx-swt.jar
> ...
>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx.properties
>   --> ERROR this file is not allowed:javafx.properties
> ...
> ----------System.err:(10/494)----------
> java.lang.Error: lib dir scan failed
> 	at CheckFiles.main(CheckFiles.java:122)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> 	at java.base/java.lang.Thread.run(Thread.java:1516)
> 
> 
> Just add javafx to allowed-list.

Marked as reviewed by kcr (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/29403#pullrequestreview-3706986975

From iris at openjdk.org  Mon Jan 26 17:10:33 2026
From: iris at openjdk.org (Iris Clark)
Date: Mon, 26 Jan 2026 17:10:33 GMT
Subject: [jdk26] RFR: 8375683: Add notes for sctp tests
In-Reply-To: <M1WePzp_OgGbHolh-dAdR4cu2E7EQpZAVKaHwLeccCc=.d87daf0f-bef3-4525-9193-63814167ab1f@github.com>
References: <M1WePzp_OgGbHolh-dAdR4cu2E7EQpZAVKaHwLeccCc=.d87daf0f-bef3-4525-9193-63814167ab1f@github.com>
Message-ID: <dc1AATm8Q3MlnUstEUzVqT9nTxYzj-NVV-asQIVEbDU=.25ad4c18-f228-40a5-a751-f1882b4202bf@github.com>

On Sun, 25 Jan 2026 01:15:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [93255602](https://github.com/openjdk/jdk/commit/932556026d6d49fe6f74d4ec4afcb72448611766) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk26 branch.
> 
> The commit being backported is add the descriptions about hwo to running the SCTP tests. Only touch the testing.md/testing/html.
> 
> Thanks!

Confirmed backport matches changes already pushed to 'master' branch.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29399#pullrequestreview-3707063527

From liach at openjdk.org  Mon Jan 26 18:07:28 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jan 2026 18:07:28 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
Message-ID: <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>

> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
> 
> 
> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
> 
> 
> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
> 
> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
> 
> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!

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

  Remove redundant dot

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29402/files
  - new: https://git.openjdk.org/jdk/pull/29402/files/f76fa06c..74af3243

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

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

PR: https://git.openjdk.org/jdk/pull/29402

From duke at openjdk.org  Tue Jan 27 01:19:48 2026
From: duke at openjdk.org (duke)
Date: Tue, 27 Jan 2026 01:19:48 GMT
Subject: RFR: 8376276: Add javafx to allowed-list of CheckFiles
In-Reply-To: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
References: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
Message-ID: <OhFrm6hrmsFZb2yZENZ2DN36SLJVd16FeKaw-nwEt7Q=.f4a7655b-3df5-42aa-833d-36223c0de9ce@github.com>

On Mon, 26 Jan 2026 02:31:11 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> ...
>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx-swt.jar
>   --> ERROR this file is not allowed:javafx-swt.jar
> ...
>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx.properties
>   --> ERROR this file is not allowed:javafx.properties
> ...
> ----------System.err:(10/494)----------
> java.lang.Error: lib dir scan failed
> 	at CheckFiles.main(CheckFiles.java:122)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> 	at java.base/java.lang.Thread.run(Thread.java:1516)
> 
> 
> Just add javafx to allowed-list.

@haominw 
Your change (at version 82e45a880d747a6e55c0e234614977855d60ba14) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29403#issuecomment-3802570107

From syan at openjdk.org  Tue Jan 27 02:28:18 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 27 Jan 2026 02:28:18 GMT
Subject: [jdk26] Integrated: 8375683: Add notes for sctp tests
In-Reply-To: <M1WePzp_OgGbHolh-dAdR4cu2E7EQpZAVKaHwLeccCc=.d87daf0f-bef3-4525-9193-63814167ab1f@github.com>
References: <M1WePzp_OgGbHolh-dAdR4cu2E7EQpZAVKaHwLeccCc=.d87daf0f-bef3-4525-9193-63814167ab1f@github.com>
Message-ID: <ra7r9gfRdxjpPASZg0PO6i6gyQnn6TNF_Q5E-Qq8Rcg=.9bbe2eec-c4ea-4750-881b-4619fd693813@github.com>

On Sun, 25 Jan 2026 01:15:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [93255602](https://github.com/openjdk/jdk/commit/932556026d6d49fe6f74d4ec4afcb72448611766) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk26 branch.
> 
> The commit being backported is add the descriptions about hwo to running the SCTP tests. Only touch the testing.md/testing/html.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 6ac3ce01
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ac3ce013e51ecc3c004d8f03c580b40ddf437ff
Stats:     42 lines in 2 files changed: 42 ins; 0 del; 0 mod

8375683: Add notes for sctp tests

Reviewed-by: erikj, iris
Backport-of: 932556026d6d49fe6f74d4ec4afcb72448611766

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

PR: https://git.openjdk.org/jdk/pull/29399

From syan at openjdk.org  Tue Jan 27 02:28:16 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 27 Jan 2026 02:28:16 GMT
Subject: [jdk26] RFR: 8375683: Add notes for sctp tests
In-Reply-To: <dc1AATm8Q3MlnUstEUzVqT9nTxYzj-NVV-asQIVEbDU=.25ad4c18-f228-40a5-a751-f1882b4202bf@github.com>
References: <M1WePzp_OgGbHolh-dAdR4cu2E7EQpZAVKaHwLeccCc=.d87daf0f-bef3-4525-9193-63814167ab1f@github.com>
 <dc1AATm8Q3MlnUstEUzVqT9nTxYzj-NVV-asQIVEbDU=.25ad4c18-f228-40a5-a751-f1882b4202bf@github.com>
Message-ID: <aziPKsVReXcrvwcsMBDUwO__clKhYpmo8GRZz2kGG-M=.2c1b34b1-ca2e-4456-aa7b-4e8121a3bfc7@github.com>

On Mon, 26 Jan 2026 17:08:17 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [93255602](https://github.com/openjdk/jdk/commit/932556026d6d49fe6f74d4ec4afcb72448611766) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk26 branch.
>> 
>> The commit being backported is add the descriptions about hwo to running the SCTP tests. Only touch the testing.md/testing/html.
>> 
>> Thanks!
>
> Confirmed backport matches changes already pushed to 'master' branch.

Thanks for the reviews @irisclark @erikj79

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

PR Comment: https://git.openjdk.org/jdk/pull/29399#issuecomment-3802722539

From wanghaomin at openjdk.org  Tue Jan 27 07:23:00 2026
From: wanghaomin at openjdk.org (Wang Haomin)
Date: Tue, 27 Jan 2026 07:23:00 GMT
Subject: RFR: 8376276: Add javafx to allowed-list of CheckFiles
In-Reply-To: <4FnM252oA3fJwCWau74uzaiFEeaY4dNL4pGFjOwvpY0=.e94ebe95-1986-4517-a2dd-214a8a9aa7f8@github.com>
References: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
 <4FnM252oA3fJwCWau74uzaiFEeaY4dNL4pGFjOwvpY0=.e94ebe95-1986-4517-a2dd-214a8a9aa7f8@github.com>
Message-ID: <pt4cogyV15G33aTJakb8TkYc8GjQiiwdScQJ7b5dJgw=.8677ff92-cfe7-4d30-83ea-6ca033ca60e3@github.com>

On Mon, 26 Jan 2026 14:14:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> ...
>>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx-swt.jar
>>   --> ERROR this file is not allowed:javafx-swt.jar
>> ...
>>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx.properties
>>   --> ERROR this file is not allowed:javafx.properties
>> ...
>> ----------System.err:(10/494)----------
>> java.lang.Error: lib dir scan failed
>> 	at CheckFiles.main(CheckFiles.java:122)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> 	at java.base/java.lang.Thread.run(Thread.java:1516)
>> 
>> 
>> Just add javafx to allowed-list.
>
> Marked as reviewed by erikj (Reviewer).

Hi, @erikj79  @kevinrushforth Could you sponsor for it?

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

PR Comment: https://git.openjdk.org/jdk/pull/29403#issuecomment-3803528403

From hannesw at openjdk.org  Tue Jan 27 09:17:38 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 Jan 2026 09:17:38 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
Message-ID: <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>

On Mon, 26 Jan 2026 18:07:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
>> 
>> 
>> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
>> 
>> 
>> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
>> 
>> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
>> 
>> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant dot

The change looks technically good. I have some questions regarding formatting of link labels which I have commented inline.

make/jdk/src/classes/build/tools/taglet/JSpec.java line 198:

> 196:                         // Change whole text to "?chapter.x" in inline tags.
> 197:                         literal = sectionSign + chapter + section;
> 198:                     }

What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)?

For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript <sup>PREVIEW</sup> tag like we use in API references.

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

PR Review: https://git.openjdk.org/jdk/pull/29402#pullrequestreview-3709994788
PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2730997254

From liach at openjdk.org  Tue Jan 27 13:34:12 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 13:34:12 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
 <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
Message-ID: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>

On Tue, 27 Jan 2026 09:08:14 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant dot
>
> make/jdk/src/classes/build/tools/taglet/JSpec.java line 198:
> 
>> 196:                         // Change whole text to "?chapter.x" in inline tags.
>> 197:                         literal = sectionSign + chapter + section;
>> 198:                     }
> 
> What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)?
> 
> For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript <sup>PREVIEW</sup> tag like we use in API references.

I don't add section sign before full title because that's how jls/jvms menu entries render.

For preview, you have a great point. I will add the superscript!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732028380

From liach at openjdk.org  Tue Jan 27 13:34:13 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 13:34:13 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
 <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
 <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>
Message-ID: <iUrvB91L8IAVyNmIuL7YRwhx_grFcTTJmlsIkFl05A0=.4542f907-d5f3-407f-84af-81544fe7a13d@github.com>

On Tue, 27 Jan 2026 13:30:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/taglet/JSpec.java line 198:
>> 
>>> 196:                         // Change whole text to "?chapter.x" in inline tags.
>>> 197:                         literal = sectionSign + chapter + section;
>>> 198:                     }
>> 
>> What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)?
>> 
>> For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript <sup>PREVIEW</sup> tag like we use in API references.
>
> I don't add section sign before full title because that's how jls/jvms menu entries render.
> 
> For preview, you have a great point. I will add the superscript!

I don't add section sign before full title because that's how jls/jvms menu entries render.

For preview, you have a great point. I will add the superscript!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732028494

From hannesw at openjdk.org  Tue Jan 27 13:51:33 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 Jan 2026 13:51:33 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <iUrvB91L8IAVyNmIuL7YRwhx_grFcTTJmlsIkFl05A0=.4542f907-d5f3-407f-84af-81544fe7a13d@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
 <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
 <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>
 <iUrvB91L8IAVyNmIuL7YRwhx_grFcTTJmlsIkFl05A0=.4542f907-d5f3-407f-84af-81544fe7a13d@github.com>
Message-ID: <NSqEC9auz8AdsQ4Go831AclUYTXVNCoWfzLwKOWV_i8=.7daba0f6-c0fc-4f09-9664-69f96fb21dbe@github.com>

On Tue, 27 Jan 2026 13:30:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I don't add section sign before full title because that's how jls/jvms menu entries render.
>> 
>> For preview, you have a great point. I will add the superscript!
>
> I don't add section sign before full title because that's how jls/jvms menu entries render.
> 
> For preview, you have a great point. I will add the superscript!

Following the spec way of rendering section links sounds reasonable to me.

If you want to use the default style for the PREVIEW superscript the following should work: `<sup class="preview-mark">PREVIEW</sup>`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732101521

From liach at openjdk.org  Tue Jan 27 14:10:05 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 14:10:05 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <NSqEC9auz8AdsQ4Go831AclUYTXVNCoWfzLwKOWV_i8=.7daba0f6-c0fc-4f09-9664-69f96fb21dbe@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
 <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
 <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>
 <iUrvB91L8IAVyNmIuL7YRwhx_grFcTTJmlsIkFl05A0=.4542f907-d5f3-407f-84af-81544fe7a13d@github.com>
 <NSqEC9auz8AdsQ4Go831AclUYTXVNCoWfzLwKOWV_i8=.7daba0f6-c0fc-4f09-9664-69f96fb21dbe@github.com>
Message-ID: <ekyStJqs2mmMUd3Ka4zYMxEBQB7bxBGzJK1CLGxdDWk=.e5533909-8be4-4165-b570-7bd8cbea2876@github.com>

On Tue, 27 Jan 2026 13:48:12 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> I don't add section sign before full title because that's how jls/jvms menu entries render.
>> 
>> For preview, you have a great point. I will add the superscript!
>
> Following the spec way of rendering section links sounds reasonable to me.
> 
> If you want to use the default style for the PREVIEW superscript the following should work: `<sup class="preview-mark">PREVIEW</sup>`

Indeed, double checked, seems we cannot link to something else for the sup unlike for regular html preview links.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732183226

From wanghaomin at openjdk.org  Tue Jan 27 14:24:52 2026
From: wanghaomin at openjdk.org (Wang Haomin)
Date: Tue, 27 Jan 2026 14:24:52 GMT
Subject: Integrated: 8376276: Add javafx to allowed-list of CheckFiles
In-Reply-To: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
References: <fU4qrgEM_YQJTlIntUe3OIv2UCTiCITCzhHN5IzHzXQ=.38f6a0ec-bbad-4f96-90f5-8d78894c44d1@github.com>
Message-ID: <UjekPdu0jJfHwUIG2SE3ucfQp7CPMO-BdEDJqF8lFaY=.a764358b-6075-4940-9c43-cffdd76b545c@github.com>

On Mon, 26 Jan 2026 02:31:11 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> ...
>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx-swt.jar
>   --> ERROR this file is not allowed:javafx-swt.jar
> ...
>   visiting file:/home/jenkins-slave/jdk/build/linux-loongarch64-server-release/images/jdk/lib/javafx.properties
>   --> ERROR this file is not allowed:javafx.properties
> ...
> ----------System.err:(10/494)----------
> java.lang.Error: lib dir scan failed
> 	at CheckFiles.main(CheckFiles.java:122)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> 	at java.base/java.lang.Thread.run(Thread.java:1516)
> 
> 
> Just add javafx to allowed-list.

This pull request has now been integrated.

Changeset: 64b0ae6b
Author:    Wang Haomin <wanghaomin at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64b0ae6be8a7b70ed4cc08333447e9b73bdcbaca
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8376276: Add javafx to allowed-list of CheckFiles

Reviewed-by: erikj, kcr

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

PR: https://git.openjdk.org/jdk/pull/29403

From liach at openjdk.org  Tue Jan 27 14:26:41 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 14:26:41 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v3]
In-Reply-To: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
Message-ID: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>

> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
> 
> 
> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
> 
> 
> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
> 
> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
> 
> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!

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

 - Add preview superscript when applicable
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance
 - Remove redundant dot
 - 8376274: JSpec preview support and output enhancement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29402/files
  - new: https://git.openjdk.org/jdk/pull/29402/files/74af3243..1e414f9f

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

  Stats: 3783 lines in 168 files changed: 1984 ins; 859 del; 940 mod
  Patch: https://git.openjdk.org/jdk/pull/29402.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29402/head:pull/29402

PR: https://git.openjdk.org/jdk/pull/29402

From hannesw at openjdk.org  Tue Jan 27 14:54:21 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 Jan 2026 14:54:21 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v3]
In-Reply-To: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>
Message-ID: <YZjERbRgc-IVqfOFvjhmw74jYjSczBe5TZzJRjxu8yI=.62966e34-275f-457b-9da7-8b73d4804e56@github.com>

On Tue, 27 Jan 2026 14:26:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
>> 
>> 
>> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
>> 
>> 
>> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
>> 
>> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
>> 
>> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Add preview superscript when applicable
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance
>  - Remove redundant dot
>  - 8376274: JSpec preview support and output enhancement

Looks good to me!

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29402#pullrequestreview-3711671933

From liach at openjdk.org  Tue Jan 27 15:08:22 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 15:08:22 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v3]
In-Reply-To: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>
Message-ID: <yIucgMDkRMmafW7qO21qng3T8MLeK6exQrFf7KXhK5w=.e58b55ee-9dea-418f-b6c2-2193756ade37@github.com>

On Tue, 27 Jan 2026 14:26:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
>> 
>> 
>> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
>> 
>> 
>> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
>> 
>> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
>> 
>> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Add preview superscript when applicable
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance
>  - Remove redundant dot
>  - 8376274: JSpec preview support and output enhancement

Thanks for the review! I need this for Valhalla (somewhat desperately) so I will integrate immediately.

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

PR Comment: https://git.openjdk.org/jdk/pull/29402#issuecomment-3805721235

From liach at openjdk.org  Tue Jan 27 15:08:24 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 15:08:24 GMT
Subject: Integrated: 8376274: JSpec preview support and output enhancement
In-Reply-To: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
Message-ID: <FFg7pV-oZqDhecnVT6jCMeOBRCC78AEdewUSluWjEKQ=.c48096be-9854-4a59-8786-e7a9cdca7d44@github.com>

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

> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
> 
> 
> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
> 
> 
> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
> 
> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
> 
> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!

This pull request has now been integrated.

Changeset: a5d0b051
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5d0b05136e34871366441a8c8e6bda5f20c617c
Stats:     65 lines in 2 files changed: 47 ins; 3 del; 15 mod

8376274: JSpec preview support and output enhancement

Reviewed-by: hannesw

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

PR: https://git.openjdk.org/jdk/pull/29402

From jwilhelm at openjdk.org  Tue Jan 27 15:59:06 2026
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 27 Jan 2026 15:59:06 GMT
Subject: [jdk26] RFR: 8376035: Remove EA from the JDK 26 version string with
 first RC promotion
Message-ID: <h5ljHDFazk2fKxU6fgIqsgpDFvGYx8YuypCsu7REFA4=.8c75fe98-6b95-41e5-8c84-5588144c9be1@github.com>

Removed EA

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

Commit messages:
 - Removed EA

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

PR: https://git.openjdk.org/jdk/pull/29453

From mikael at openjdk.org  Tue Jan 27 16:01:16 2026
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 27 Jan 2026 16:01:16 GMT
Subject: [jdk26] RFR: 8376035: Remove EA from the JDK 26 version string
 with first RC promotion
In-Reply-To: <h5ljHDFazk2fKxU6fgIqsgpDFvGYx8YuypCsu7REFA4=.8c75fe98-6b95-41e5-8c84-5588144c9be1@github.com>
References: <h5ljHDFazk2fKxU6fgIqsgpDFvGYx8YuypCsu7REFA4=.8c75fe98-6b95-41e5-8c84-5588144c9be1@github.com>
Message-ID: <C6_IXpW-wJZjh9Htm4b4bP7_i6JU1ZZ_VABkuWQuyRA=.6c3a8b03-5d5c-427b-9e1e-502bbd6f3976@github.com>

On Tue, 27 Jan 2026 15:50:31 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removed EA

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29453#pullrequestreview-3712052553

From iris at openjdk.org  Tue Jan 27 16:18:59 2026
From: iris at openjdk.org (Iris Clark)
Date: Tue, 27 Jan 2026 16:18:59 GMT
Subject: [jdk26] RFR: 8376035: Remove EA from the JDK 26 version string
 with first RC promotion
In-Reply-To: <h5ljHDFazk2fKxU6fgIqsgpDFvGYx8YuypCsu7REFA4=.8c75fe98-6b95-41e5-8c84-5588144c9be1@github.com>
References: <h5ljHDFazk2fKxU6fgIqsgpDFvGYx8YuypCsu7REFA4=.8c75fe98-6b95-41e5-8c84-5588144c9be1@github.com>
Message-ID: <9geM9ZHHXefp_FmSPdWG_SyrXyZvJqScw3F3uRv_wZQ=.16d1004d-944e-4378-b040-5d0b77ec600f@github.com>

On Tue, 27 Jan 2026 15:50:31 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removed EA

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29453#pullrequestreview-3712139947

From jlahoda at openjdk.org  Tue Jan 27 16:29:03 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Jan 2026 16:29:03 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v14]
In-Reply-To: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
Message-ID: <u4SwLihnTlWhlJtl-Sw-JUXxFSdaGa-PuJ8bb7I0TjQ=.ab2eb162-8c62-4063-96ec-7544a4a83ceb@github.com>

> Consider code like:
> 
> package test;
> public class Test {
>     private int test(Root r) {
>         return switch (r) {
>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>         };
>     }
>     sealed interface Base {}
>     record R1() implements Base {}
>     record R2(Base b1) implements Base {}
>     record Root(R2 b2, R2 b3) {}
> }
> ``` 
> 
> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
> 
> $ javac test/Test.java
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
> 1 error
> 
> 
> The goal of this PR is to improve the error, at least in some cases to something along these lines:
> 
> $ javac test/Test.java 
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
>   missing patterns:
>       Root(R2(R2 _), R2(R2 _))
> 1 error
> 
> 
> The (very simplified) way it works in a recursive (or induction) way:
> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
> - for a current missing pattern, try to enhance it:
>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
> 
> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
> 
> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
> 
> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
> 
> There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated.

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Fixing tests.
 - Renaming checkTimeout, as suggested.
 - Cleanup: using fragments as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27256/files
  - new: https://git.openjdk.org/jdk/pull/27256/files/8f1ea6b9..1c17012f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=12-13

  Stats: 269 lines in 19 files changed: 138 ins; 92 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/27256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27256/head:pull/27256

PR: https://git.openjdk.org/jdk/pull/27256

From jlahoda at openjdk.org  Tue Jan 27 16:29:05 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Jan 2026 16:29:05 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <1MCPn8qLXtQCTcILUi0FH21LnRRTGkgYxDKD9neBhIs=.401b342d-c71e-4710-af87-e8b288c22fd0@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <sci1FRa4wDhZ9QTBFHMBDvAcyLG32H6c1pVzuBG3cWg=.6db14001-ad13-4d9d-97c4-f14f4a2df976@github.com>
 <ko8G3gAmJ492gUOCSDNhFzkrdcDZ2msQ-1Ibd8RgZ_Y=.676dbbe4-3cc1-45ab-8f34-177086f116ee@github.com>
 <1MCPn8qLXtQCTcILUi0FH21LnRRTGkgYxDKD9neBhIs=.401b342d-c71e-4710-af87-e8b288c22fd0@github.com>
Message-ID: <eZNA1EBYuomNx9bKYTnKhUDXUm8gEOTHisDc0yh4tbo=.48800e6d-d0ad-4a54-8b0e-b91a7143fec2@github.com>

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

>> That said, in Rich formatter we also need to preprocess, so perhaps keeping the code as is here would be more symmetric...
>
> I suppose overall I'm not entirely sure if, at this point, pattern descriptions should be pattern descriptions, or already translated into some kind of fragment -- because the code in formatters can deal with fragments recursively very well -- but can do less so with objects.

I tried to convert to fragments, feels better now - thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2732834629

From jlahoda at openjdk.org  Tue Jan 27 16:33:12 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Jan 2026 16:33:12 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <kUGppMQMVPS6xeWpiRLsQSNmd4fEnH3BSiOSHb6tcf0=.f54b8a2e-f305-474e-b025-7ad895d60bd8@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <kUGppMQMVPS6xeWpiRLsQSNmd4fEnH3BSiOSHb6tcf0=.f54b8a2e-f305-474e-b025-7ad895d60bd8@github.com>
Message-ID: <-AxInZIuLG1SPafqSaZBsL9quFkuSvFyrBKJ21SvFsU=.813cb07e-7d7b-48e1-846c-7dacead54c0a@github.com>

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

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 771:
> 
>> 769:                     exhaustivenessResult.notExhaustiveDetails()
>> 770:                                        .stream()
>> 771:                                        .sorted((pd1, pd2) -> pd1.toString().compareTo(pd2.toString()))
> 
> Maybe we could have pattern descriptions be comparable?

The sorting now uses JCDiagnostic; to me, using a comparator for lexicographical ordering seems OK, although I can investigate other options if desired.

> src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java line 215:
> 
>> 213:      */
>> 214:     protected void preprocessArgument(Object arg) {
>> 215:         //TODO: preprocess for patterns
> 
> Is this comment this valid?

Removed, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2732852046
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2732853155

From jlahoda at openjdk.org  Tue Jan 27 16:43:11 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Jan 2026 16:43:11 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v15]
In-Reply-To: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
Message-ID: <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>

> Consider code like:
> 
> package test;
> public class Test {
>     private int test(Root r) {
>         return switch (r) {
>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>         };
>     }
>     sealed interface Base {}
>     record R1() implements Base {}
>     record R2(Base b1) implements Base {}
>     record Root(R2 b2, R2 b3) {}
> }
> ``` 
> 
> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
> 
> $ javac test/Test.java
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
> 1 error
> 
> 
> The goal of this PR is to improve the error, at least in some cases to something along these lines:
> 
> $ javac test/Test.java 
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
>   missing patterns:
>       Root(R2(R2 _), R2(R2 _))
> 1 error
> 
> 
> The (very simplified) way it works in a recursive (or induction) way:
> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
> - for a current missing pattern, try to enhance it:
>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
> 
> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
> 
> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
> 
> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
> 
> There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27256/files
  - new: https://git.openjdk.org/jdk/pull/27256/files/1c17012f..a164fd1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=13-14

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

PR: https://git.openjdk.org/jdk/pull/27256

From jlahoda at openjdk.org  Tue Jan 27 16:43:12 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Jan 2026 16:43:12 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <m99SqXYs7kBO5NANDfh87PLcHEEDvre2Nc7RRLGNr5s=.1d96e254-1d92-49e1-9efe-a74ebc5eca0c@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <w7W5OfAbXv10mMiwTUkQj6gGlY2TXVQ_uoRNqlR7-50=.35de3b38-4059-4d35-8710-9d76bb46dab7@github.com>
 <65Rgv2InuhjHS1sWTQhXtw-ihBy5N4vi-llhZKNDch0=.47cc956d-df60-4db6-a9d8-21c0974c6ed6@github.com>
 <xWGy332zK_nQJNWboJR9TsCPm15gdOFn7ioiN0fGVVU=.b710510d-e7ad-4afc-8a9d-cf1f449f6407@github.com>
 <m99SqXYs7kBO5NANDfh87PLcHEEDvre2Nc7RRLGNr5s=.1d96e254-1d92-49e1-9efe-a74ebc5eca0c@github.com>
Message-ID: <clfDllDPm0vC_i7Dmxc9h4QTw5Oz4tF34YmgNrCNaZU=.e8b0ab6b-764b-46b7-8745-c69e1ad663b4@github.com>

On Mon, 26 Jan 2026 12:21:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Also, `isBpCovered` seems to be called by routines (like `reduceRecordPattern`) that do not seem related to the new logic (which is what got me suspicious about the location of the update to begin with). Which has (at least in theory) potential for `TooManyChecksException` to trigger in places where it's not expected? (but maybe that's handled by the special value `-1` which is carefully set after the new logic runs)
>
> A possible suggestion might be to add this check inside `doExpandMissingPatternDescriptions` -- after the `if (toExpand instanceof BindingPattern bp) {` ?

I've renamed the method. I also tried to put the check it on some other places; but unfortunately I couldn't find a better place where setting a sensible value (i.e. such that would not cancel tests in `ExhaustivenessConvenientErrors.java`, but would cancel `Exhaustiveness.testDeeplyNestedNotExhaustive`). 

Yes, during the "real" run, `baseChecks` should be `-`, and that should prevent the cancelation from happening.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2732893680

From jlahoda at openjdk.org  Tue Jan 27 16:43:17 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Jan 2026 16:43:17 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <kUGppMQMVPS6xeWpiRLsQSNmd4fEnH3BSiOSHb6tcf0=.f54b8a2e-f305-474e-b025-7ad895d60bd8@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <kUGppMQMVPS6xeWpiRLsQSNmd4fEnH3BSiOSHb6tcf0=.f54b8a2e-f305-474e-b025-7ad895d60bd8@github.com>
Message-ID: <UNET94h8ejjc-B7vIWTfW39vULFMU31myH6kPJq6YmA=.ac9a9ee1-11f6-438b-b081-9602fc3045e7@github.com>

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

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Attempting to use the number of 'base checks' as the limit, instead of wall-clock time.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 43:
> 
>> 41: # option name       the name of a command line option
>> 42: # path              a path
>> 43: # patter            a pattern/pattern description
> 
> Suggestion:
> 
> # pattern            a pattern/pattern description

Cleaned (the pattern is now removed, as fragments are used anyway).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2732874704

From erikj at openjdk.org  Tue Jan 27 16:53:57 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 27 Jan 2026 16:53:57 GMT
Subject: [jdk26] RFR: 8376035: Remove EA from the JDK 26 version string
 with first RC promotion
In-Reply-To: <h5ljHDFazk2fKxU6fgIqsgpDFvGYx8YuypCsu7REFA4=.8c75fe98-6b95-41e5-8c84-5588144c9be1@github.com>
References: <h5ljHDFazk2fKxU6fgIqsgpDFvGYx8YuypCsu7REFA4=.8c75fe98-6b95-41e5-8c84-5588144c9be1@github.com>
Message-ID: <DVP4H6qBCbk6OI6CsjWH8AbTFbLv1W3Lz4otnYTUA-s=.86fceed9-930c-4364-b6a3-511dfc8a1e00@github.com>

On Tue, 27 Jan 2026 15:50:31 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removed EA

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29453#pullrequestreview-3712332610

From vromero at openjdk.org  Tue Jan 27 23:52:30 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 27 Jan 2026 23:52:30 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v15]
In-Reply-To: <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
Message-ID: <xNORYc0zA5u4DxiSjeP_7rfE1uqoEhi9i6Ozs5hQQhg=.dbe721cf-aba0-4539-9025-9e5b63c59a92@github.com>

On Tue, 27 Jan 2026 16:43:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 945:

> 943:                                                                                       combination.map(BindingPattern::new)
> 944:                                                                                                  .toArray(PatternDescription[]::new)))
> 945:                                                 .collect(Collectors.toCollection(HashSet::new));

LinkedHashSet better here? So that we have the same order between compilations?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2734283421

From vromero at openjdk.org  Wed Jan 28 00:43:39 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Jan 2026 00:43:39 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v15]
In-Reply-To: <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
Message-ID: <KMCt1l-pegvLNAwrPBY6l0_D6Mhxo1vmNwB3A5088iY=.e5ca38fb-7bc9-4f20-85c8-5b63b1c4922f@github.com>

On Tue, 27 Jan 2026 16:43:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 1226:

> 1224:     }
> 1225: 
> 1226:     /* The stricness of determining the equivalent of patterns, used in

typo: strictness

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2734380206

From vromero at openjdk.org  Wed Jan 28 02:30:57 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Jan 2026 02:30:57 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v15]
In-Reply-To: <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
Message-ID: <eE0UyAShSz_oXr-wcYKY-vMdg8KOK5qGo6P26Yqdz0M=.c7001884-9c93-4fad-b620-f5d9a65c956a@github.com>

On Tue, 27 Jan 2026 16:43:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java line 51:

> 49: import com.sun.tools.javac.code.Type;
> 50: import com.sun.tools.javac.code.Type.CapturedType;
> 51: import com.sun.tools.javac.comp.ExhaustivenessComputer.BindingPattern;

the only changes in this file are imports

src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java line 50:

> 48: import static com.sun.tools.javac.code.Kinds.*;
> 49: import static com.sun.tools.javac.code.Kinds.Kind.*;
> 50: import com.sun.tools.javac.comp.ExhaustivenessComputer.BindingPattern;

same here

test/langtools/tools/javac/diags/Example.java line 605:

> 603:         private static void scanForKeys(JCDiagnostic d, Set<String> keys) {
> 604:             keys.add(d.getCode());
> 605:             List<Object> todoArgs = new ArrayList<>(Arrays.asList(d.getArgs()));

why this change?

test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java line 562:

> 560:         new JavacTask(tb)
> 561:             .options("-XDrawDiagnostics",
> 562:                      "-XDdev",

nit: we don't seem to be using this compiler option

test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java line 563:

> 561:             .options("-XDrawDiagnostics",
> 562:                      "-XDdev",
> 563:                      "-Xlint:-preview",

is this preview option necessary?

test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java line 585:

> 583:             })
> 584:             .run(Task.Expect.FAIL)
> 585:             .writeAll()

nit: the compilation output is being ignored

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2734407743
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2734408292
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2734444447
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2734543181
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2734551313
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2734544045

From vromero at openjdk.org  Wed Jan 28 02:33:30 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Jan 2026 02:33:30 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v15]
In-Reply-To: <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
Message-ID: <C05fG_lTgVYPbEQJmbGy3mgX-L6E8iOauNazNXsMujY=.52d113cf-7321-4094-a742-6fe8ce22d22d@github.com>

On Tue, 27 Jan 2026 16:43:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

great job, as a follow-up, it could be useful to have a way to generate debug info, under a debug option, to generate some info about the process that could be useful to inspect or debug the algo

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

PR Comment: https://git.openjdk.org/jdk/pull/27256#issuecomment-3808608342

From mcimadamore at openjdk.org  Wed Jan 28 08:57:26 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Jan 2026 08:57:26 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v15]
In-Reply-To: <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
Message-ID: <Gt_S8lU0n_uMz18Pw3PW_QqMDOYPYGXh_0XXXWGiFB0=.c8609af4-47a8-457e-a903-f9992ccf82e0@github.com>

On Tue, 27 Jan 2026 16:43:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

Looks great -- I have no further comments!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27256#pullrequestreview-3715357977

From mcimadamore at openjdk.org  Wed Jan 28 08:57:28 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Jan 2026 08:57:28 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <clfDllDPm0vC_i7Dmxc9h4QTw5Oz4tF34YmgNrCNaZU=.e8b0ab6b-764b-46b7-8745-c69e1ad663b4@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <w7W5OfAbXv10mMiwTUkQj6gGlY2TXVQ_uoRNqlR7-50=.35de3b38-4059-4d35-8710-9d76bb46dab7@github.com>
 <65Rgv2InuhjHS1sWTQhXtw-ihBy5N4vi-llhZKNDch0=.47cc956d-df60-4db6-a9d8-21c0974c6ed6@github.com>
 <xWGy332zK_nQJNWboJR9TsCPm15gdOFn7ioiN0fGVVU=.b710510d-e7ad-4afc-8a9d-cf1f449f6407@github.com>
 <m99SqXYs7kBO5NANDfh87PLcHEEDvre2Nc7RRLGNr5s=.1d96e254-1d92-49e1-9efe-a74ebc5eca0c@github.com>
 <clfDllDPm0vC_i7Dmxc9h4QTw5Oz4tF34YmgNrCNaZU=.e8b0ab6b-764b-46b7-8745-c69e1ad663b4@github.com>
Message-ID: <mpWW9SidWbhYzhv-J57sCwrDfSg8-Kz7rTJVeShNays=.5d217bd6-bac7-462d-8076-0c3826d80698@github.com>

On Tue, 27 Jan 2026 16:39:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A possible suggestion might be to add this check inside `doExpandMissingPatternDescriptions` -- after the `if (toExpand instanceof BindingPattern bp) {` ?
>
> I've renamed the method. I also tried to put the check it on some other places; but unfortunately I couldn't find a better place where setting a sensible value (i.e. such that would not cancel tests in `ExhaustivenessConvenientErrors.java`, but would cancel `Exhaustiveness.testDeeplyNestedNotExhaustive`). 
> 
> Yes, during the "real" run, `baseChecks` should be `-`, and that should prevent the cancelation from happening.

For now let's keep the code as is, and see how this goes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2735528240

From mcimadamore at openjdk.org  Wed Jan 28 08:57:29 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Jan 2026 08:57:29 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v13]
In-Reply-To: <mpWW9SidWbhYzhv-J57sCwrDfSg8-Kz7rTJVeShNays=.5d217bd6-bac7-462d-8076-0c3826d80698@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <fsqEVhjNa0klagkqajjaHzYQo8aHr8Py_NFiRM4DJlQ=.174ea081-9306-433b-9d97-3752022ecf42@github.com>
 <w7W5OfAbXv10mMiwTUkQj6gGlY2TXVQ_uoRNqlR7-50=.35de3b38-4059-4d35-8710-9d76bb46dab7@github.com>
 <65Rgv2InuhjHS1sWTQhXtw-ihBy5N4vi-llhZKNDch0=.47cc956d-df60-4db6-a9d8-21c0974c6ed6@github.com>
 <xWGy332zK_nQJNWboJR9TsCPm15gdOFn7ioiN0fGVVU=.b710510d-e7ad-4afc-8a9d-cf1f449f6407@github.com>
 <m99SqXYs7kBO5NANDfh87PLcHEEDvre2Nc7RRLGNr5s=.1d96e254-1d92-49e1-9efe-a74ebc5eca0c@github.com>
 <clfDllDPm0vC_i7Dmxc9h4QTw5Oz4tF34YmgNrCNaZU=.e8b0ab6b-764b-46b7-8745-c69e1ad663b4@github.com>
 <mpWW9SidWbhYzhv-J57sCwrDfSg8-Kz7rTJVeShNays=.5d217bd6-bac7-462d-8076-0c3826d80698@github.com>
Message-ID: <tQbe2uedj3cYszh0gIVxV8fgUutkgNZzoFinyO58ODg=.26b239da-30c4-4a1c-9364-5b6f24eeb2a0@github.com>

On Wed, 28 Jan 2026 08:53:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've renamed the method. I also tried to put the check it on some other places; but unfortunately I couldn't find a better place where setting a sensible value (i.e. such that would not cancel tests in `ExhaustivenessConvenientErrors.java`, but would cancel `Exhaustiveness.testDeeplyNestedNotExhaustive`). 
>> 
>> Yes, during the "real" run, `baseChecks` should be `-`, and that should prevent the cancelation from happening.
>
> For now let's keep the code as is, and see how this goes

(Maybe add a comment saying that the -1 is quite crucial to avoid exceptions being triggered in unexpected places).

Another option could be to have a checker object that does nothing in normal paths, but then would be "reassigned" before the exhaustiveness logic kicks in to keep a count and throw an exception. Up to you -- it won't completely remove the problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2735533937

From jlahoda at openjdk.org  Wed Jan 28 14:26:04 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 28 Jan 2026 14:26:04 GMT
Subject: RFR: 8376585: bin/update_copyright_year.sh could allow updating a
 specified list of files
Message-ID: <d-A6pvfZvSvT-IU5heV0uc51lLgOSScDC4fQa5uI124=.c56b26f2-79e9-4ea4-94a9-728f60ab1f8c@github.com>

There's a script to update copyright years for all files inside changesets in a given branch:
bin/update_copyright_year.sh

Unfortunately, this is not always ideal for development branches: development branches may contain changes to files that are reverted to the original state later in that branch. As commits inside development branches are squashed at the end, these files are not updated in the final commits, and the copyright headers should not be updated.

My proposal here is to augment bin/update_copyright_year.sh with an ability to update the years for a given list of files. The list of files is read from stdin. Then one can use a command line like:

$ git diff upstream/master...<branch-name> | lsdiff | cut -d '/' -f 2- | bash bin/update_copyright_year.sh -m

To update the years for all files really modified on a given branch.

I am not an expert on shell/bash, so it is quite possible there are some mistakes here.

What do you think? Thanks!

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

Commit messages:
 - 8376585: bin/update_copyright_year.sh could allow updating a specified list of files

Changes: https://git.openjdk.org/jdk/pull/29467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376585
  Stats: 121 lines in 1 file changed: 45 ins; 23 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/29467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29467/head:pull/29467

PR: https://git.openjdk.org/jdk/pull/29467

From erikj at openjdk.org  Wed Jan 28 14:43:54 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Jan 2026 14:43:54 GMT
Subject: RFR: 8376585: bin/update_copyright_year.sh could allow updating a
 specified list of files
In-Reply-To: <d-A6pvfZvSvT-IU5heV0uc51lLgOSScDC4fQa5uI124=.c56b26f2-79e9-4ea4-94a9-728f60ab1f8c@github.com>
References: <d-A6pvfZvSvT-IU5heV0uc51lLgOSScDC4fQa5uI124=.c56b26f2-79e9-4ea4-94a9-728f60ab1f8c@github.com>
Message-ID: <Co5j1v7yyQWOnfGSA8VdPFqHZ2MBO89APVdZHj-_4Ao=.15b1d9ec-45c8-42a7-a047-8fd2c87aa0a8@github.com>

On Wed, 28 Jan 2026 14:18:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There's a script to update copyright years for all files inside changesets in a given branch:
> bin/update_copyright_year.sh
> 
> Unfortunately, this is not always ideal for development branches: development branches may contain changes to files that are reverted to the original state later in that branch. As commits inside development branches are squashed at the end, these files are not updated in the final commits, and the copyright headers should not be updated.
> 
> My proposal here is to augment bin/update_copyright_year.sh with an ability to update the years for a given list of files. The list of files is read from stdin. Then one can use a command line like:
> 
> $ git diff upstream/master...<branch-name> | lsdiff | cut -d '/' -f 2- | bash bin/update_copyright_year.sh -m
> 
> To update the years for all files really modified on a given branch.
> 
> I am not an expert on shell/bash, so it is quite possible there are some mistakes here.
> 
> What do you think? Thanks!

I think this seems fine. Did you consider taking a file as input instead, but allowing a file argument of `-` to mean read from stdin? That seems to be a common behavior in the Unix world and would offer more flexibility. Not sure if it's worth doing, just a thought.

bin/update_copyright_year.sh line 29:

> 27: #  (Originally from xdono, Thanks!)
> 28: 
> 29: # To update Copyright years in for changes in a specific branch,

Suggestion:

# To update Copyright years for changes in a specific branch,

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

PR Review: https://git.openjdk.org/jdk/pull/29467#pullrequestreview-3717046782
PR Review Comment: https://git.openjdk.org/jdk/pull/29467#discussion_r2736929598

From jlahoda at openjdk.org  Wed Jan 28 16:27:56 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 28 Jan 2026 16:27:56 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v15]
In-Reply-To: <C05fG_lTgVYPbEQJmbGy3mgX-L6E8iOauNazNXsMujY=.52d113cf-7321-4094-a742-6fe8ce22d22d@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <_jI37E2FW9LIRixY9tiQlcX8tL0Ghc2sXq5PA4iOhNw=.7ce01f44-b70a-4497-b6e2-9dfa3ab8f189@github.com>
 <C05fG_lTgVYPbEQJmbGy3mgX-L6E8iOauNazNXsMujY=.52d113cf-7321-4094-a742-6fe8ce22d22d@github.com>
Message-ID: <G_4ATPcPB-YK0idaNcEKBXvh8FVTm5ZzFDdUY-BoDyU=.0054aa5c-1a4e-48f7-922c-c674357b1c3e@github.com>

On Wed, 28 Jan 2026 02:31:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup.
>
> great job, as a follow-up, it could be useful to have a way to generate debug info, under a debug option, to generate some info about the process that could be useful to inspect or debug the algo

I did a cleanup as suggested by @vicente-romero-oracle (https://github.com/openjdk/jdk/pull/27256/commits/ae71272ae5c6e6cec850dbe383f7218af37f3295), made the `-1` in `baseChecks` more explicit by introducing a constant (`NO_BASE_CHECKS_COUNTING` - https://github.com/openjdk/jdk/pull/27256/changes/65e2fd0ae7f62fe2e34495c3d2ea6cb89db4cb0b) and updated years in copyright headers (https://github.com/openjdk/jdk/pull/27256/commits/539760bc91d50fe2729e6afa12dff3ae93ec8f20). Please let me know if there's something that needs improvement.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27256#issuecomment-3812291506

From jlahoda at openjdk.org  Wed Jan 28 16:27:54 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 28 Jan 2026 16:27:54 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
Message-ID: <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>

> Consider code like:
> 
> package test;
> public class Test {
>     private int test(Root r) {
>         return switch (r) {
>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>         };
>     }
>     sealed interface Base {}
>     record R1() implements Base {}
>     record R2(Base b1) implements Base {}
>     record Root(R2 b2, R2 b3) {}
> }
> ``` 
> 
> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
> 
> $ javac test/Test.java
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
> 1 error
> 
> 
> The goal of this PR is to improve the error, at least in some cases to something along these lines:
> 
> $ javac test/Test.java 
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
>   missing patterns:
>       Root(R2(R2 _), R2(R2 _))
> 1 error
> 
> 
> The (very simplified) way it works in a recursive (or induction) way:
> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
> - for a current missing pattern, try to enhance it:
>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
> 
> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
> 
> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
> 
> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
> 
> There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated.

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Updating copyright headers.
 - Making the skipping of base checks more clear.
 - Reflecting review feedback - cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27256/files
  - new: https://git.openjdk.org/jdk/pull/27256/files/a164fd1f..539760bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=14-15

  Stats: 42 lines in 14 files changed: 6 ins; 16 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27256/head:pull/27256

PR: https://git.openjdk.org/jdk/pull/27256

From vromero at openjdk.org  Wed Jan 28 17:58:18 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Jan 2026 17:58:18 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
Message-ID: <Q-FtMMpGoAXvjp3sFgK-NA7Vsu2IiROLxEK546SzaKE=.47d2f9a9-f77b-4ead-9f94-be305be1f800@github.com>

On Wed, 28 Jan 2026 16:27:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Updating copyright headers.
>  - Making the skipping of base checks more clear.
>  - Reflecting review feedback - cleanup.

looks good to me

test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java line 333:

> 331:                            case Root(R2 _, R2(R1 _, R2 _), R2(R1 _, R1 _)) -> 0;
> 332:                            case Root(R2 _, R2(R1 _, R2 _), R2(R1 _, R2 _)) -> 0;
> 333: //                           case Root(R2 _, R2(R1 _, R2 _), R2(R2 _, R1 _)) -> 0;

it could be confusing to have commented code in a test, I guess probably to just remove the commented code?

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27256#pullrequestreview-3718158393
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2737828639

From jlahoda at openjdk.org  Wed Jan 28 18:52:11 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 28 Jan 2026 18:52:11 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <Q-FtMMpGoAXvjp3sFgK-NA7Vsu2IiROLxEK546SzaKE=.47d2f9a9-f77b-4ead-9f94-be305be1f800@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
 <Q-FtMMpGoAXvjp3sFgK-NA7Vsu2IiROLxEK546SzaKE=.47d2f9a9-f77b-4ead-9f94-be305be1f800@github.com>
Message-ID: <FKzlNQ7fr4qZHRf3YxRUC2UlWQ3Hl1snUsxN4IMAh_I=.3b8f129e-adea-4b11-ba49-60f8b630eb42@github.com>

On Wed, 28 Jan 2026 17:54:57 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Updating copyright headers.
>>  - Making the skipping of base checks more clear.
>>  - Reflecting review feedback - cleanup.
>
> test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java line 333:
> 
>> 331:                            case Root(R2 _, R2(R1 _, R2 _), R2(R1 _, R1 _)) -> 0;
>> 332:                            case Root(R2 _, R2(R1 _, R2 _), R2(R1 _, R2 _)) -> 0;
>> 333: //                           case Root(R2 _, R2(R1 _, R2 _), R2(R2 _, R1 _)) -> 0;
> 
> it could be confusing to have commented code in a test, I guess probably to just remove the commented code?

These commented-out cases are the ones that are missing from the switch to be exhaustive. I kept them there intentionally, so see what the user might have missed, so that it can be compared with what javac reports. I can add comments to them if desired.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2738037816

From jlahoda at openjdk.org  Wed Jan 28 18:55:53 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 28 Jan 2026 18:55:53 GMT
Subject: RFR: 8376585: bin/update_copyright_year.sh could allow updating a
 specified list of files [v2]
In-Reply-To: <d-A6pvfZvSvT-IU5heV0uc51lLgOSScDC4fQa5uI124=.c56b26f2-79e9-4ea4-94a9-728f60ab1f8c@github.com>
References: <d-A6pvfZvSvT-IU5heV0uc51lLgOSScDC4fQa5uI124=.c56b26f2-79e9-4ea4-94a9-728f60ab1f8c@github.com>
Message-ID: <Q2H2rOBzc0a54Cfjlix1VRL8ArvHKfrWIXl_8-PMlwk=.418b1f1c-7100-40fc-89e3-6779144db4cf@github.com>

> There's a script to update copyright years for all files inside changesets in a given branch:
> bin/update_copyright_year.sh
> 
> Unfortunately, this is not always ideal for development branches: development branches may contain changes to files that are reverted to the original state later in that branch. As commits inside development branches are squashed at the end, these files are not updated in the final commits, and the copyright headers should not be updated.
> 
> My proposal here is to augment bin/update_copyright_year.sh with an ability to update the years for a given list of files. The list of files is read from stdin. Then one can use a command line like:
> 
> $ git diff upstream/master...<branch-name> | lsdiff | cut -d '/' -f 2- | bash bin/update_copyright_year.sh -m
> 
> To update the years for all files really modified on a given branch.
> 
> I am not an expert on shell/bash, so it is quite possible there are some mistakes here.
> 
> What do you think? Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Allowing to specify a file to read the file list from, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29467/files
  - new: https://git.openjdk.org/jdk/pull/29467/files/8495999b..c25145bf

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

  Stats: 12 lines in 1 file changed: 1 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/29467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29467/head:pull/29467

PR: https://git.openjdk.org/jdk/pull/29467

From jlahoda at openjdk.org  Wed Jan 28 19:01:21 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 28 Jan 2026 19:01:21 GMT
Subject: RFR: 8376585: bin/update_copyright_year.sh could allow updating a
 specified list of files [v2]
In-Reply-To: <Co5j1v7yyQWOnfGSA8VdPFqHZ2MBO89APVdZHj-_4Ao=.15b1d9ec-45c8-42a7-a047-8fd2c87aa0a8@github.com>
References: <d-A6pvfZvSvT-IU5heV0uc51lLgOSScDC4fQa5uI124=.c56b26f2-79e9-4ea4-94a9-728f60ab1f8c@github.com>
 <Co5j1v7yyQWOnfGSA8VdPFqHZ2MBO89APVdZHj-_4Ao=.15b1d9ec-45c8-42a7-a047-8fd2c87aa0a8@github.com>
Message-ID: <JanfzKl-wUwndJTUgOaASJsHYpz1DHW3BUJfxO2qqJw=.10bbcf14-430b-40bb-92cb-c8a1fbd43879@github.com>

On Wed, 28 Jan 2026 14:41:22 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think this seems fine. Did you consider taking a file as input instead, but allowing a file argument of `-` to mean read from stdin? That seems to be a common behavior in the Unix world and would offer more flexibility. Not sure if it's worth doing, just a thought.

Thanks, done in [c25145b](https://github.com/openjdk/jdk/pull/29467/commits/c25145bffdb235a254db9cd390b13a68370dec15).

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

PR Comment: https://git.openjdk.org/jdk/pull/29467#issuecomment-3813271392

From erikj at openjdk.org  Wed Jan 28 20:35:51 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Jan 2026 20:35:51 GMT
Subject: RFR: 8376585: bin/update_copyright_year.sh could allow updating a
 specified list of files [v2]
In-Reply-To: <Q2H2rOBzc0a54Cfjlix1VRL8ArvHKfrWIXl_8-PMlwk=.418b1f1c-7100-40fc-89e3-6779144db4cf@github.com>
References: <d-A6pvfZvSvT-IU5heV0uc51lLgOSScDC4fQa5uI124=.c56b26f2-79e9-4ea4-94a9-728f60ab1f8c@github.com>
 <Q2H2rOBzc0a54Cfjlix1VRL8ArvHKfrWIXl_8-PMlwk=.418b1f1c-7100-40fc-89e3-6779144db4cf@github.com>
Message-ID: <3JVJvyfE3dHBaL_z_OzbrRUXbo9Y9XiyKcngfTAdQzY=.3921079c-a1ef-4043-a38a-f089e743a099@github.com>

On Wed, 28 Jan 2026 18:55:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> There's a script to update copyright years for all files inside changesets in a given branch:
>> bin/update_copyright_year.sh
>> 
>> Unfortunately, this is not always ideal for development branches: development branches may contain changes to files that are reverted to the original state later in that branch. As commits inside development branches are squashed at the end, these files are not updated in the final commits, and the copyright headers should not be updated.
>> 
>> My proposal here is to augment bin/update_copyright_year.sh with an ability to update the years for a given list of files. The list of files is read from stdin. Then one can use a command line like:
>> 
>> $ git diff upstream/master...<branch-name> | lsdiff | cut -d '/' -f 2- | bash bin/update_copyright_year.sh -m
>> 
>> To update the years for all files really modified on a given branch.
>> 
>> I am not an expert on shell/bash, so it is quite possible there are some mistakes here.
>> 
>> What do you think? Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allowing to specify a file to read the file list from, as suggested.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29467#pullrequestreview-3719031405

From duke at openjdk.org  Thu Jan 29 20:36:47 2026
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 29 Jan 2026 20:36:47 GMT
Subject: RFR: 8374045: Add support to run benchmarking with fragmented
 CodeCache
Message-ID: <28XEl5CuISOqvXzqKriK_Syebek7Txgot5gD_yVD8vo=.07dabc2f-2f2b-4faa-b85f-03ad6e222a1c@github.com>

[JDK-8374045](https://bugs.openjdk.org/browse/JDK-8374045)

This PR adds a new utility tool CodeCacheFragmenter to help with testing HotSpot code cache fragmentation scenarios. The tool is a Java agent that uses the WhiteBox API to create and randomly free dummy code blobs in the NonProfiled code heap to achieve a specified fill percentage. It includes configurable parameters for blob sizes, target fill percentage (0-100%), and random seeding to enable reproducible fragmentation patterns. The utility is built via a standard Makefile and produces `codecachefragmenter.jar` which can be used as a Java agent with `-javaagent` flag. This tool is intended for performance testing and experimentation with code cache behavior under various fragmentation conditions.

This is useful to show the performance benefits of [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205)

With the same amount of free code cache memory, adding fragmentation increases execution time of Renaissance Dotty by ~5x. See https://github.com/openjdk/jdk/pull/28934#issuecomment-3820151693 for more details.

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into CodeCacheFragAgent
 - Small improvements
 - Make README markdown
 - Implement build system
 - Add CodeCacheFragAgent

Changes: https://git.openjdk.org/jdk/pull/28934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374045
  Stats: 331 lines in 5 files changed: 331 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28934/head:pull/28934

PR: https://git.openjdk.org/jdk/pull/28934

From duke at openjdk.org  Thu Jan 29 20:36:48 2026
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 29 Jan 2026 20:36:48 GMT
Subject: RFR: 8374045: Add support to run benchmarking with fragmented
 CodeCache
In-Reply-To: <28XEl5CuISOqvXzqKriK_Syebek7Txgot5gD_yVD8vo=.07dabc2f-2f2b-4faa-b85f-03ad6e222a1c@github.com>
References: <28XEl5CuISOqvXzqKriK_Syebek7Txgot5gD_yVD8vo=.07dabc2f-2f2b-4faa-b85f-03ad6e222a1c@github.com>
Message-ID: <seTNIPcxAgIdbAHbB_hF9oAunA0TFnOrTgWLaY_mdng=.8f1a38cf-3d46-4529-af06-dd186aa28bd6@github.com>

On Fri, 19 Dec 2025 20:08:20 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8374045](https://bugs.openjdk.org/browse/JDK-8374045)
> 
> This PR adds a new utility tool CodeCacheFragmenter to help with testing HotSpot code cache fragmentation scenarios. The tool is a Java agent that uses the WhiteBox API to create and randomly free dummy code blobs in the NonProfiled code heap to achieve a specified fill percentage. It includes configurable parameters for blob sizes, target fill percentage (0-100%), and random seeding to enable reproducible fragmentation patterns. The utility is built via a standard Makefile and produces `codecachefragmenter.jar` which can be used as a Java agent with `-javaagent` flag. This tool is intended for performance testing and experimentation with code cache behavior under various fragmentation conditions.
> 
> This is useful to show the performance benefits of [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205)
> 
> With the same amount of free code cache memory, adding fragmentation increases execution time of Renaissance Dotty by ~5x. See https://github.com/openjdk/jdk/pull/28934#issuecomment-3820151693 for more details.

Performance results for 3 runs. All runs have 64m of usable code cache for C2 code.

1. NonProfiledCodeHeapSize=64m with no fragmentation. 
2. NonProfiledCodeHeapSize=128m with half (64m) filled up with dummy blobs
3. NonProfiledCodeHeapSize=112m with half (56m) filled up with dummy blobs and 8m of HotCodeCache using #27858

The results show that code cache fragmentation can significantly degrade performance. Introducing fragmentation increases execution time by ~5x and is accompanied by a large increase in branch mispredictions (~7x).

Run 3 utilizes [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205) which shows grouping hot code can significantly improve performance reducing the degradation from ~5x to ~1.5x.


# Run1 (No frag)
perf stat ./build/linux-aarch64-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysPreTouch -XX:+PrintCodeCache -XX:-TieredCompilation -XX:ReservedCodeCacheSize=72m -XX:InitialCodeCacheSize=72m -XX:+SegmentedCodeCache -XX:+WhiteBoxAPI -XX:NonNMethodCodeHeapSize=8m -XX:ProfiledCodeHeapSize=0 -XX:NonProfiledCodeHeapSize=64m -jar renaissance-mit-0.16.0.jar -r 1190 dotty

...
====== dotty (scala) [default], iteration 1188 completed (746.699 ms) ======
====== dotty (scala) [default], iteration 1189 completed (748.863 ms) ======

 Performance counter stats:

        3031251.35 msec task-clock:u                     #    2.164 CPUs utilized
                 0      context-switches:u               #    0.000 /sec
                 0      cpu-migrations:u                 #    0.000 /sec       
         199250260      page-faults:u                    #   65.732 K/sec  
     3224539067410      cycles:u                         #    1.064 GHz
     6062234799740      instructions:u                   #    1.88  insn per cycle
   <not supported>      branches:u                                         
       28253496347      branch-misses:u                    

    1401.045295428 seconds time elapsed

    1262.547605000 seconds user
    1769.354116000 seconds sys



# Run 2 (128m 0.5frag 0mHCH)
perf stat ./build/linux-aarch64-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysPreTouch -XX:+PrintCodeCache -XX:-TieredCompilation -XX:ReservedCodeCacheSize=136m -XX:InitialCodeCacheSize=136m -XX:+SegmentedCodeCache -XX:+WhiteBoxAPI -XX:NonNMethodCodeHeapSize=8m -XX:ProfiledCodeHeapSize=0 -XX:NonProfiledCodeHeapSize=128m -XX:+WhiteBoxAPI -javaagent:codecachefragmenter.jar=FillPercentage=50.0,RandomSeed=42 -Xbootclasspath/a:codecachefragmenter.jar -jar renaissance-mit-0.16.0.jar -r 1190 dotty

====== dotty (scala) [default], iteration 1188 completed (4022.919 ms) ======
====== dotty (scala) [default], iteration 1189 completed (4038.655 ms) ======

 Performance counter stats:

        6321396.03 msec task-clock:u                     #    1.135 CPUs utilized
                 0      context-switches:u               #    0.000 /sec        
                 0      cpu-migrations:u                 #    0.000 /sec   
          70083590      page-faults:u                    #   11.087 K/sec
    14233471439404      cycles:u                         #    2.252 GHz        
    15400934891881      instructions:u                   #    1.08  insn per cycle
   <not supported>      branches:u                         
      200741000177      branch-misses:u                                         

    5568.255657415 seconds time elapsed

    5498.865476000 seconds user 
     824.319759000 seconds sys



# Run 3 (112m 0.5frag 8mHCH)
perf stat ./build/linux-aarch64-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysPreTouch -XX:+PrintCodeCache -XX:-TieredCompilation -XX:ReservedCodeCacheSize=128m -XX:InitialCodeCacheSize=128m -XX:+SegmentedCodeCache -XX:+WhiteBoxAPI -XX:NonNMethodCodeHeapSize=8m -XX:ProfiledCodeHeapSize=0 -XX:NonProfiledCodeHeapSize=112m -XX:+HotCodeHeap -XX:HotCodeHeapSize=8m -XX:+WhiteBoxAPI -javaagent:codecachefragmenter.jar=FillPercentage=50.0,RandomSeed=42 -Xbootclasspath/a:codecachefragmenter.jar -jar renaissance-mit-0.16.0.jar -r 1190 dotty

====== dotty (scala) [default], iteration 1188 completed (1137.186 ms) ======
====== dotty (scala) [default], iteration 1189 completed (1134.037 ms) ======

 Performance counter stats:

        3936522.85 msec task-clock:u                     #    1.466 CPUs utilized
                 0      context-switches:u               #    0.000 /sec   
                 0      cpu-migrations:u                 #    0.000 /sec
         119342149      page-faults:u                    #   30.317 K/sec       
     7050404447349      cycles:u                         #    1.791 GHz    
     9984653084133      instructions:u                   #    1.42  insn per cycle
   <not supported>      branches:u                                             
       74832021136      branch-misses:u                                    

    2684.809939553 seconds time elapsed

    2735.116925000 seconds user 
    1203.549873000 seconds sys

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

PR Comment: https://git.openjdk.org/jdk/pull/28934#issuecomment-3820151693

From duke at openjdk.org  Thu Jan 29 21:26:48 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Thu, 29 Jan 2026 21:26:48 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11
 libraries
Message-ID: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>

This to support linux headless mode without X11. E.g. A headless server.

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

Commit messages:
 - 8376684: doc: fix X11 description when compiling headless
 - 8376684: autoconf: libraries: drop the need for X11 in headless mode
 - 8376684: awt: fix HEADLESS compilation without X11

Changes: https://git.openjdk.org/jdk/pull/28310/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28310&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376684
  Stats: 30 lines in 5 files changed: 14 ins; 5 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28310.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28310/head:pull/28310

PR: https://git.openjdk.org/jdk/pull/28310

From duke at openjdk.org  Thu Jan 29 21:26:49 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Thu, 29 Jan 2026 21:26:49 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <DQIeaI_nfW7rR76exzm02r0CDc_uoHfxPPd--YAilxc=.46506560-1105-44bc-9e7e-2207f06d15f0@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

> Hi @ThomasDevoogdt, welcome to this OpenJDK project and thanks for contributing!
> 
> We do not recognize you as [Contributor](https://openjdk.java.net/bylaws#contributor) and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow [the instructions](https://oca.opensource.oracle.com/). Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing `/signed` in a comment in this pull request.
> 
> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user ThomasDevoogdt" as summary for the issue.
> 
> If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing `/covered` in a comment in this pull request.

@zhaosongzs I don't know who to address here. I can't create an issue for this PR as I don't have an OpenJDK account. I'm also awaiting OCA.

Hi all, the buildroot people have merged this functionality upstream (https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3). Is it also possible to handle this PR here?

@tstuefe @magicus

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3531547157
PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3531574662
PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3710324642

From zsong at openjdk.org  Thu Jan 29 21:26:49 2026
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 29 Jan 2026 21:26:49 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <Fa_XRTzHi99tHO9-9l1v70XKl3p07M4TBokcXW14PNA=.d0d8d428-af2e-4792-9c86-b457ccbe3210@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

@robilad will handle your OCA when he is available.

For the jbs issue,  you need to ask someone with jbs account to create the issue for you.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3533868907

From duke at openjdk.org  Thu Jan 29 21:26:50 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Thu, 29 Jan 2026 21:26:50 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <Fa_XRTzHi99tHO9-9l1v70XKl3p07M4TBokcXW14PNA=.d0d8d428-af2e-4792-9c86-b457ccbe3210@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <Fa_XRTzHi99tHO9-9l1v70XKl3p07M4TBokcXW14PNA=.d0d8d428-af2e-4792-9c86-b457ccbe3210@github.com>
Message-ID: <SgB7--Gh88Pf2WW7adwVvMmfpDjLC0Lf6X2Ny4W8z64=.c0f0fad4-b315-4f0c-a93a-60db6301ce26@github.com>

On Fri, 14 Nov 2025 17:42:47 GMT, Zhao Song <zsong at openjdk.org> wrote:

> @robilad will handle your OCA when he is available.
> 
> For the jbs issue,  you need to ask someone with jbs account to create the issue for you.

@zhaosongzs And who is someone? I'm not affiliated with oracle, I don't know who to address. Ideally I could just leave it from here, and having someone who picks this up for me.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3534081614

From kcr at openjdk.org  Thu Jan 29 21:26:51 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Jan 2026 21:26:51 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <SgB7--Gh88Pf2WW7adwVvMmfpDjLC0Lf6X2Ny4W8z64=.c0f0fad4-b315-4f0c-a93a-60db6301ce26@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <Fa_XRTzHi99tHO9-9l1v70XKl3p07M4TBokcXW14PNA=.d0d8d428-af2e-4792-9c86-b457ccbe3210@github.com>
 <SgB7--Gh88Pf2WW7adwVvMmfpDjLC0Lf6X2Ny4W8z64=.c0f0fad4-b315-4f0c-a93a-60db6301ce26@github.com>
Message-ID: <Jua-TSMiU1SaiXCPj3AWj_j2gWW2z11RWZJohKlzpP0=.63eb0278-35fb-48e0-9c44-3e3d4e3425e2@github.com>

On Fri, 14 Nov 2025 18:39:55 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

>> @robilad will handle your OCA when he is available.
>> 
>> For the jbs issue,  you need to ask someone with jbs account to create the issue for you.
>
>> @robilad will handle your OCA when he is available.
>> 
>> For the jbs issue,  you need to ask someone with jbs account to create the issue for you.
> 
> @zhaosongzs And who is someone? I'm not affiliated with oracle, I don't know who to address. Ideally I could just leave it from here, and having someone who picks this up for me.

@ThomasDevoogdt I recommend you read the OpenJDK Developers' guide, particularly [this section on proposing changes to the OpenJDK code](https://openjdk.org/guide/#things-to-consider-before-proposing-changes-to-openjdk-code). The mailing list on which to discuss this proposed change is [client-libs-dev at openjdk.org](mailto:client-libs-dev at openjdk.org).

As for the OCA, if you work for an employer who is already an OCA signatory, which is what entering `/covered` means, no action is needed from you at this time. If you don't, you need to follow the instructions in the OpenJDK Developer's Guide to sign it as an individual contributor, and enter `/signed` in a comment. Either way, you will need to wait for your OCA to be processed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3534908960

From stuefe at openjdk.org  Thu Jan 29 21:26:52 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 29 Jan 2026 21:26:52 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

ping @magicus

Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in.

But I am no expert in this area; @magicus and @prrace should look at this.

If this gets pushed, downporting it to LTSes is possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3616561369
PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3816620358

From duke at openjdk.org  Thu Jan 29 21:26:53 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Thu, 29 Jan 2026 21:26:53 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
Message-ID: <ZY7Mirv_R2UiSTGphyP1tF763ZELVzWOZMJmIkGiGso=.70febef7-9824-4db6-96f9-7ea79c3828e9@github.com>

On Fri, 5 Dec 2025 11:46:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This to support linux headless mode without X11. E.g. A headless server.
>
> ping @magicus

@tstuefe @magicus ping ... 
And is it possible that someone already create an official issue number for it, so that I can finish all the formal stuff?

> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in.
> 
> But I am no expert in this area; @magicus and @prrace should look at this.
> 
> If this gets pushed, downporting it to LTSes is possible.

Thanks for creating the issue. I've updated the commits with the issue tag.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3638535424
PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820397618

From aivanov at openjdk.org  Thu Jan 29 21:26:54 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Jan 2026 21:26:54 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <DQIeaI_nfW7rR76exzm02r0CDc_uoHfxPPd--YAilxc=.46506560-1105-44bc-9e7e-2207f06d15f0@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <DQIeaI_nfW7rR76exzm02r0CDc_uoHfxPPd--YAilxc=.46506560-1105-44bc-9e7e-2207f06d15f0@github.com>
Message-ID: <IiKyED5yhWgurhlZdpOxR0SSl0JpvRKciexpOrv1tec=.603d963d-33e7-46c4-86b5-24094a8728d0@github.com>

On Mon, 5 Jan 2026 12:59:31 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

>> This to support linux headless mode without X11. E.g. A headless server.
>
> Hi all, the buildroot people have merged this functionality upstream (https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3). Is it also possible to handle this PR here?
> 
> @tstuefe @magicus

@ThomasDevoogdt A PR isn't announced on the mailing list until it's *ready for review* which includes a valid JBS bug.

I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf.

If I have time, I'll test your patch locally and run it in the Oracle CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3712001940

From duke at openjdk.org  Thu Jan 29 21:26:55 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Thu, 29 Jan 2026 21:26:55 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <DQIeaI_nfW7rR76exzm02r0CDc_uoHfxPPd--YAilxc=.46506560-1105-44bc-9e7e-2207f06d15f0@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <DQIeaI_nfW7rR76exzm02r0CDc_uoHfxPPd--YAilxc=.46506560-1105-44bc-9e7e-2207f06d15f0@github.com>
Message-ID: <CZLDDc-7B8yEuPCQqSFX_GlpMiOBgUd8bZ5yrnZBArc=.92d73c4a-72c2-4f8a-8099-758928bf1623@github.com>

On Mon, 5 Jan 2026 12:59:31 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

>> This to support linux headless mode without X11. E.g. A headless server.
>
> Hi all, the buildroot people have merged this functionality upstream (https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3). Is it also possible to handle this PR here?
> 
> @tstuefe @magicus

> @ThomasDevoogdt A PR isn't announced on the mailing list until it's *ready for review* which includes a valid JBS bug.
> 
> I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf.

@aivanov-jdk Yes, please do so! 

> If I have time, I'll test your patch locally and run it in the Oracle CI.

Yeah, sorry for all the spam, but I really really don't know how to get any attention here. I simply don't understand how to file a bug without account, how to announce a change and so on. So every little help is much appreciated! Thx!

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3712135725

From duke at openjdk.org  Thu Jan 29 21:26:55 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Thu, 29 Jan 2026 21:26:55 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <IiKyED5yhWgurhlZdpOxR0SSl0JpvRKciexpOrv1tec=.603d963d-33e7-46c4-86b5-24094a8728d0@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <DQIeaI_nfW7rR76exzm02r0CDc_uoHfxPPd--YAilxc=.46506560-1105-44bc-9e7e-2207f06d15f0@github.com>
 <IiKyED5yhWgurhlZdpOxR0SSl0JpvRKciexpOrv1tec=.603d963d-33e7-46c4-86b5-24094a8728d0@github.com>
Message-ID: <pSXD8Fcn172cT1Mttg8S6N32uiU7d2wCi6_8AlUVLVY=.2a9d3303-ca64-4bae-ad75-e8ecd91a0d2c@github.com>

On Mon, 5 Jan 2026 20:36:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Hi all, the buildroot people have merged this functionality upstream (https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3). Is it also possible to handle this PR here?
>> 
>> @tstuefe @magicus
>
> @ThomasDevoogdt A PR isn't announced on the mailing list until it's *ready for review* which includes a valid JBS bug.
> 
> I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf.
> 
> If I have time, I'll test your patch locally and run it in the Oracle CI.

@aivanov-jdk ping

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3769989683

From dholmes at openjdk.org  Thu Jan 29 21:49:24 2026
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jan 2026 21:49:24 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <3REbDAeUgHla11SMvGGwt518wd1m1MEwXz-A48xRdcs=.28410df3-fb72-4185-b84c-1a90e4811483@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

I just updated the JBS issue with a couple of links. This is certainly not a new issue and there is an existing RFE to deal with the source code dependencies on X11.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820573064

From aivanov at openjdk.org  Thu Jan 29 22:14:09 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Jan 2026 22:14:09 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <9vC8xA88gjCkT7b2H1tjbNURPIGOqYRgqRxBZXoahWM=.59e0a718-c0d1-4329-bebf-af1267bc05bc@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

This looks like a regression then.

[JDK-8255785](https://bugs.openjdk.org/browse/JDK-8255785) made it possible, see https://github.com/openjdk/jdk/commit/f97ec359

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820700275

From aivanov at openjdk.org  Thu Jan 29 22:17:26 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Jan 2026 22:17:26 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <ZY7Mirv_R2UiSTGphyP1tF763ZELVzWOZMJmIkGiGso=.70febef7-9824-4db6-96f9-7ea79c3828e9@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
 <ZY7Mirv_R2UiSTGphyP1tF763ZELVzWOZMJmIkGiGso=.70febef7-9824-4db6-96f9-7ea79c3828e9@github.com>
Message-ID: <qxATmLINrhsEZTgx4Di9knt-fnl482D4Kdh08OdIUmo=.500fec87-c0cb-43a9-82a0-6e2aecbb293b@github.com>

On Thu, 29 Jan 2026 21:18:42 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

>> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in.
>> 
>> But I am no expert in this area; @magicus and @prrace should look at this.
>> 
>> If this gets pushed, downporting it to LTSes is possible.
>
>> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in.
>> 
>> But I am no expert in this area; @magicus and @prrace should look at this.
>> 
>> If this gets pushed, downporting it to LTSes is possible.
> 
> Thanks for creating the issue. I've updated the commits with the issue tag.

@ThomasDevoogdt Please, *do not force-push any more*. Instead, pull changes from upstream master and *merge* master into your branch.

Force-pushing invalidates comments left in the code review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820709314

From prr at openjdk.org  Thu Jan 29 22:35:36 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 Jan 2026 22:35:36 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <ZY7Mirv_R2UiSTGphyP1tF763ZELVzWOZMJmIkGiGso=.70febef7-9824-4db6-96f9-7ea79c3828e9@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
 <ZY7Mirv_R2UiSTGphyP1tF763ZELVzWOZMJmIkGiGso=.70febef7-9824-4db6-96f9-7ea79c3828e9@github.com>
Message-ID: <uDJcqvMy9l9x-AlJcJ9e5iPH1If2EvmAYJ-wfzEq6bY=.8973bffa-3888-4769-b9a5-9befde1215f2@github.com>

On Thu, 29 Jan 2026 21:18:42 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

>> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in.
>> 
>> But I am no expert in this area; @magicus and @prrace should look at this.
>> 
>> If this gets pushed, downporting it to LTSes is possible.
>
>> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in.
>> 
>> But I am no expert in this area; @magicus and @prrace should look at this.
>> 
>> If this gets pushed, downporting it to LTSes is possible.
> 
> Thanks for creating the issue. I've updated the commits with the issue tag.

> @ThomasDevoogdt A PR isn't announced on the mailing list until it's _ready for review_ which includes a valid JBS bug.
> 
> I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf.
> 
> If I have time, I'll test your patch locally and run it in the Oracle CI.

All our build systems have X11. So a test build there doesn't prove much, and also it can easily regress.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820768881

From duke at openjdk.org  Fri Jan 30 07:44:10 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Fri, 30 Jan 2026 07:44:10 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <3REbDAeUgHla11SMvGGwt518wd1m1MEwXz-A48xRdcs=.28410df3-fb72-4185-b84c-1a90e4811483@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <3REbDAeUgHla11SMvGGwt518wd1m1MEwXz-A48xRdcs=.28410df3-fb72-4185-b84c-1a90e4811483@github.com>
Message-ID: <fzfxaHNg9ZyvKdEaSy-bV2bDlfyQy4Pu5k1uM9uzm98=.4d710c9a-bd4a-4c6f-9746-762db282eca3@github.com>

On Thu, 29 Jan 2026 21:46:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This to support linux headless mode without X11. E.g. A headless server.
>
> I just updated the JBS issue with a couple of links. This is certainly not a new issue and there is an existing RFE to deal with the source code dependencies on X11.

@dholmes-ora @aivanov-jdk @prrace I can see that there are duplicated issues on this topic, and that regression is easy without proper testing, but is that a reason to not merge this kind of code? If new regressions occurs, then chances are big that someone will notice them, and push a new fix for it.

Yes, buildroot is a bit behind upstream JDK, but at least there we will see it. https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3 Other distributions might also be interested.

Are there actions needed on my side? Because that is not clear out of the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3822314701

From mbaesken at openjdk.org  Fri Jan 30 09:45:22 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jan 2026 09:45:22 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all
 or not called from PRODUCT code
Message-ID: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>

libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.

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

Commit messages:
 - JDK-8376703

Changes: https://git.openjdk.org/jdk/pull/29502/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29502&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376703
  Stats: 69 lines in 5 files changed: 0 ins; 69 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29502.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29502/head:pull/29502

PR: https://git.openjdk.org/jdk/pull/29502

From alanb at openjdk.org  Fri Jan 30 12:28:47 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Jan 2026 12:28:47 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code
In-Reply-To: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
Message-ID: <lr0-vsKmqBQ4m5Ei9H7r3O1vZtJYQGHKuWqkaUhmRpk=.aadf17fd-daa3-490b-b962-fdc692fd7f91@github.com>

On Fri, 30 Jan 2026 09:30:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.

This looks okay but would be good to confirm what builds + testing were done. Also can you update the Oracle copyright on these files as it's the first change to them in 2026.

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3823506738

From mbaesken at openjdk.org  Fri Jan 30 12:41:33 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jan 2026 12:41:33 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
Message-ID: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>

> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust COPYRIGHT headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29502/files
  - new: https://git.openjdk.org/jdk/pull/29502/files/bcfda923..8a68ef39

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

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29502.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29502/head:pull/29502

PR: https://git.openjdk.org/jdk/pull/29502

From mbaesken at openjdk.org  Fri Jan 30 12:48:20 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jan 2026 12:48:20 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code
In-Reply-To: <lr0-vsKmqBQ4m5Ei9H7r3O1vZtJYQGHKuWqkaUhmRpk=.aadf17fd-daa3-490b-b962-fdc692fd7f91@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <lr0-vsKmqBQ4m5Ei9H7r3O1vZtJYQGHKuWqkaUhmRpk=.aadf17fd-daa3-490b-b962-fdc692fd7f91@github.com>
Message-ID: <NF0eaStDrdrSoUGYASboh1pNbjsEhKg54u_8yIMvSZI=.1162c153-f6d9-47d9-8900-e97310d4acc9@github.com>

On Fri, 30 Jan 2026 12:26:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks okay but would be good to confirm what builds + testing were done. Also can you update the Oracle copyright on these files as it's the first change to them in 2026.

I adjusted the COPYRIGHT headers .
Builds are okay (AIX, Linux, macOS , Windows).  Tests  (jtreg HS and JDK) look so far good as well, but on some slower platforms a number of  tiers still have to be executed (will most likely follow in the next few hours) .

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3823582723

From mbaesken at openjdk.org  Fri Jan 30 12:55:07 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jan 2026 12:55:07 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
Message-ID: <FAuPYJi9LgadWpg_tshOyGLQHby2k5uriVWffXlSmEI=.89d1bd97-2d4a-46b7-a94d-0566c549cce5@github.com>

On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
>> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
>> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT headers

one interesting finding seems to be that  the linktime-gc can eliminate more methods like
`ZipDecompressor::decompress(void*, unsigned long, void*, unsigned long, char**)`

which is printed as removed  

`
/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: removing unused section '.text._ZN15ZipDecompressor10decompressEPvyS0_yPPc' in file '/builddir/support/native/java.base/libjimage/imageDecompressor.o'`

but this is not unused/uncalled in our codebase.  I think it is inlined at the 1 or 2  points were it is used.  But the method is still generated into the library even in case that it is always inlined ;  it may be difficult to address this with the usual linker settings on Linux  (means without linktime-gc or LTO or similar stuff ) .

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3823600664

From aivanov at openjdk.org  Fri Jan 30 12:56:09 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 Jan 2026 12:56:09 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <uDJcqvMy9l9x-AlJcJ9e5iPH1If2EvmAYJ-wfzEq6bY=.8973bffa-3888-4769-b9a5-9befde1215f2@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
 <ZY7Mirv_R2UiSTGphyP1tF763ZELVzWOZMJmIkGiGso=.70febef7-9824-4db6-96f9-7ea79c3828e9@github.com>
 <uDJcqvMy9l9x-AlJcJ9e5iPH1If2EvmAYJ-wfzEq6bY=.8973bffa-3888-4769-b9a5-9befde1215f2@github.com>
Message-ID: <4T5cSAaROTH9gsM3k0xeQxujShyN7JaW_E6TCewGTjY=.0349f633-1b2f-439b-a09d-7de741f794ac@github.com>

On Thu, 29 Jan 2026 22:32:46 GMT, Phil Race <prr at openjdk.org> wrote:

> > If I have time, I'll test your patch locally and run it in the Oracle CI.
> 
> All our build systems have X11. So a test build there doesn't prove much, and also it can easily regress.

This is why I'm going to use a VM which doesn't have X11 headers installed.

> is that a reason to not merge this kind of code?

I think it's a good change. Looking at the history at which @dholmes-ora pointed, building headless JDK without X11 was supported, but it has become broken again.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3823612106

From erikj at openjdk.org  Fri Jan 30 14:49:35 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 30 Jan 2026 14:49:35 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <UTfWE_rtXIUKJ8QH8Zu08TvDFbtn9lzaz0gMLnXa5kk=.bfa8acbb-a326-4ff7-9b97-63074683702b@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

>From a build point of view, this looks fine. Someone from client will need to review it too.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28310#pullrequestreview-3728768954

From cstein at openjdk.org  Fri Jan 30 16:19:07 2026
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 30 Jan 2026 16:19:07 GMT
Subject: RFR: 8376355: Update to use jtreg 8.2.1
Message-ID: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>

Please review the change to update to using jtreg 8.2.1.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

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

Commit messages:
 - 8376355: Update to use jtreg 8.2.1
 - 8376355: Update to use jtreg 8.2

Changes: https://git.openjdk.org/jdk/pull/29452/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376355
  Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/29452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29452/head:pull/29452

PR: https://git.openjdk.org/jdk/pull/29452

From iris at openjdk.org  Fri Jan 30 16:28:47 2026
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Jan 2026 16:28:47 GMT
Subject: RFR: 8376355: Update to use jtreg 8.2.1
In-Reply-To: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
References: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
Message-ID: <HlQbPR20S1Dg9oFgg6l2aH9cp_Iu_o7WW0V-sKCdy7w=.1b846595-e379-4004-a035-a4381b34b2a7@github.com>

On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.2.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29452#pullrequestreview-3729267371

From erikj at openjdk.org  Fri Jan 30 17:46:27 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 30 Jan 2026 17:46:27 GMT
Subject: RFR: 8376355: Update to use jtreg 8.2.1
In-Reply-To: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
References: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
Message-ID: <sTOR_uoAU-xUspoYNXwaXUwTpU0W2uk5537w_JeVfuI=.c612e323-c0ee-4e2e-b2c5-88f81362f03c@github.com>

On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.2.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29452#pullrequestreview-3729610652

From dcubed at openjdk.org  Fri Jan 30 20:47:42 2026
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jan 2026 20:47:42 GMT
Subject: RFR: 8376751: add preview project anchors to main-line ProblemList
 files
Message-ID: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>

A trivial fix to add preview project anchors to main-line ProblemList files.

Also backports changes from the Valhalla repo to make/RunTests.gmk
to support ProblemList-coh.txt files. This PR also includes the new
ProblemList-coh.txt file, but it contains no entries (yet). Since this is
NOT a complete backport of the changes for:

- [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332

I'm not handling it as a backport issue.

I've also added missing Copyright headers to some files.

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

Commit messages:
 - Merge branch 'master' into JDK-8376751
 - 8376751: add preview project anchors to main-line ProblemList files

Changes: https://git.openjdk.org/jdk/pull/29509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29509&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376751
  Stats: 402 lines in 26 files changed: 380 ins; 2 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/29509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29509/head:pull/29509

PR: https://git.openjdk.org/jdk/pull/29509

From kvn at openjdk.org  Fri Jan 30 21:44:27 2026
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 30 Jan 2026 21:44:27 GMT
Subject: RFR: 8376751: add preview project anchors to main-line ProblemList
 files
In-Reply-To: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
References: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
Message-ID: <J_tqutdeyTpEcPOLY52y6gJm0GraMzHjuQgGTIJhX9c=.4af70532-26b6-4611-a7f0-a14125f70347@github.com>

On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to add preview project anchors to main-line ProblemList files.
> 
> Also backports changes from the Valhalla repo to make/RunTests.gmk
> to support ProblemList-coh.txt files. This PR also includes the new
> ProblemList-coh.txt file, but it contains no entries (yet). Since this is
> NOT a complete backport of the changes for:
> 
> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332
> 
> I'm not handling it as a backport issue.
> 
> I've also added missing Copyright headers to some files.

Marked as reviewed by kvn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730502656

From liach at openjdk.org  Fri Jan 30 21:44:29 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jan 2026 21:44:29 GMT
Subject: RFR: 8376751: add preview project anchors to main-line ProblemList
 files
In-Reply-To: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
References: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
Message-ID: <bgoxqi7BTBdiIugS8bRzY86AngbL0aLWh46WQOHFWhI=.0ae578b2-89da-4bba-ac3a-4505fd1cbcec@github.com>

On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to add preview project anchors to main-line ProblemList files.
> 
> Also backports changes from the Valhalla repo to make/RunTests.gmk
> to support ProblemList-coh.txt files. This PR also includes the new
> ProblemList-coh.txt file, but it contains no entries (yet). Since this is
> NOT a complete backport of the changes for:
> 
> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332
> 
> I'm not handling it as a backport issue.
> 
> I've also added missing Copyright headers to some files.

test/langtools/ProblemList-enable-preview.txt line 2:

> 1: #
> 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved.

Suggestion:

# Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748067121

From rriggs at openjdk.org  Fri Jan 30 22:11:03 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 30 Jan 2026 22:11:03 GMT
Subject: RFR: 8376751: add preview project anchors to main-line ProblemList
 files
In-Reply-To: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
References: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
Message-ID: <DWCliAmg7TJrBvqVVEXArJD5Llet9mye6wuD0bgC71o=.0fbaaaa8-3a32-485c-8bf8-5560b09737b5@github.com>

On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to add preview project anchors to main-line ProblemList files.
> 
> Also backports changes from the Valhalla repo to make/RunTests.gmk
> to support ProblemList-coh.txt files. This PR also includes the new
> ProblemList-coh.txt file, but it contains no entries (yet). Since this is
> NOT a complete backport of the changes for:
> 
> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332
> 
> I'm not handling it as a backport issue.
> 
> I've also added missing Copyright headers to some files.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730618431

From liach at openjdk.org  Fri Jan 30 22:11:05 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jan 2026 22:11:05 GMT
Subject: RFR: 8376751: add preview project anchors to main-line ProblemList
 files
In-Reply-To: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
References: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
Message-ID: <VyP47LbkaupaRdE49D9Van5exYr1Qz8Cb46kNbxS5cQ=.b7e18ef9-1813-491a-b696-1376a173d1e6@github.com>

On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to add preview project anchors to main-line ProblemList files.
> 
> Also backports changes from the Valhalla repo to make/RunTests.gmk
> to support ProblemList-coh.txt files. This PR also includes the new
> ProblemList-coh.txt file, but it contains no entries (yet). Since this is
> NOT a complete backport of the changes for:
> 
> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332
> 
> I'm not handling it as a backport issue.
> 
> I've also added missing Copyright headers to some files.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730624896

From dcubed at openjdk.org  Fri Jan 30 22:11:07 2026
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jan 2026 22:11:07 GMT
Subject: RFR: 8376751: add preview project anchors to main-line ProblemList
 files
In-Reply-To: <bgoxqi7BTBdiIugS8bRzY86AngbL0aLWh46WQOHFWhI=.0ae578b2-89da-4bba-ac3a-4505fd1cbcec@github.com>
References: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
 <bgoxqi7BTBdiIugS8bRzY86AngbL0aLWh46WQOHFWhI=.0ae578b2-89da-4bba-ac3a-4505fd1cbcec@github.com>
Message-ID: <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com>

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

>> A trivial fix to add preview project anchors to main-line ProblemList files.
>> 
>> Also backports changes from the Valhalla repo to make/RunTests.gmk
>> to support ProblemList-coh.txt files. This PR also includes the new
>> ProblemList-coh.txt file, but it contains no entries (yet). Since this is
>> NOT a complete backport of the changes for:
>> 
>> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332
>> 
>> I'm not handling it as a backport issue.
>> 
>> I've also added missing Copyright headers to some files.
>
> test/langtools/ProblemList-enable-preview.txt line 2:
> 
>> 1: #
>> 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
> # Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved.

Good catch. In the main-line repo the file is new in 2026, but in the Valhalla repo, the proper copyright is "2025, 2026"...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748155579

From liach at openjdk.org  Fri Jan 30 22:11:07 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jan 2026 22:11:07 GMT
Subject: RFR: 8376751: add preview project anchors to main-line ProblemList
 files
In-Reply-To: <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com>
References: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
 <bgoxqi7BTBdiIugS8bRzY86AngbL0aLWh46WQOHFWhI=.0ae578b2-89da-4bba-ac3a-4505fd1cbcec@github.com>
 <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com>
Message-ID: <c7GuOMG9ppm9GSIyBKcA7kF9jbvMh__eLk15M8i5qDs=.4d934776-9750-467e-b491-426cdab13df3@github.com>

On Fri, 30 Jan 2026 22:04:58 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/langtools/ProblemList-enable-preview.txt line 2:
>> 
>>> 1: #
>>> 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved.
>> 
>> Suggestion:
>> 
>> # Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved.
>
> Good catch. In the main-line repo the file is new in 2026, but in the Valhalla repo, the proper copyright is "2025, 2026"...

Sure, we can inherit the valhalla copyright years.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748166677

From dcubed at openjdk.org  Fri Jan 30 22:28:51 2026
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jan 2026 22:28:51 GMT
Subject: RFR: 8376751: add preview project anchors to main-line ProblemList
 files
In-Reply-To: <J_tqutdeyTpEcPOLY52y6gJm0GraMzHjuQgGTIJhX9c=.4af70532-26b6-4611-a7f0-a14125f70347@github.com>
References: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
 <J_tqutdeyTpEcPOLY52y6gJm0GraMzHjuQgGTIJhX9c=.4af70532-26b6-4611-a7f0-a14125f70347@github.com>
Message-ID: <oktUnIyepMXuynZHr0IWm0Re4t7s_hjl1hIlk0B5Pi0=.93249631-f347-4cf7-b40a-710ff1914268@github.com>

On Fri, 30 Jan 2026 21:40:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> A trivial fix to add preview project anchors to main-line ProblemList files.
>> 
>> Also backports changes from the Valhalla repo to make/RunTests.gmk
>> to support ProblemList-coh.txt files. This PR also includes the new
>> ProblemList-coh.txt file, but it contains no entries (yet). Since this is
>> NOT a complete backport of the changes for:
>> 
>> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332
>> 
>> I'm not handling it as a backport issue.
>> 
>> I've also added missing Copyright headers to some files.
>
> Marked as reviewed by kvn (Reviewer).

@vnkozlov, @liach, and @RogerRiggs - Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/29509#issuecomment-3826088183

From dcubed at openjdk.org  Fri Jan 30 22:40:52 2026
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jan 2026 22:40:52 GMT
Subject: Integrated: 8376751: add preview project anchors to main-line
 ProblemList files
In-Reply-To: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
References: <i48Cfwy1jjsBQJQbQDV_e8GawolYK4H-hKj5ht8CYas=.beb8b4a9-6285-4e36-a323-1f10cde593e4@github.com>
Message-ID: <yKbRl6iyKlligPQpRWGGgSSR4S_Swot6eIO_-1LcOCw=.2ae2f7ca-2308-4548-b649-1e42486cb9fa@github.com>

On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to add preview project anchors to main-line ProblemList files.
> 
> Also backports changes from the Valhalla repo to make/RunTests.gmk
> to support ProblemList-coh.txt files. This PR also includes the new
> ProblemList-coh.txt file, but it contains no entries (yet). Since this is
> NOT a complete backport of the changes for:
> 
> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332
> 
> I'm not handling it as a backport issue.
> 
> I've also added missing Copyright headers to some files.

This pull request has now been integrated.

Changeset: 6ce2f3e1
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ce2f3e18f31d1dbffc2c4f5adbb5dfe91613989
Stats:     402 lines in 26 files changed: 380 ins; 2 del; 20 mod

8376751: add preview project anchors to main-line ProblemList files

Reviewed-by: kvn, rriggs, liach

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

PR: https://git.openjdk.org/jdk/pull/29509

From alanb at openjdk.org  Sat Jan 31 16:28:00 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 31 Jan 2026 16:28:00 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <FAuPYJi9LgadWpg_tshOyGLQHby2k5uriVWffXlSmEI=.89d1bd97-2d4a-46b7-a94d-0566c549cce5@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
 <FAuPYJi9LgadWpg_tshOyGLQHby2k5uriVWffXlSmEI=.89d1bd97-2d4a-46b7-a94d-0566c549cce5@github.com>
Message-ID: <Vyow0B_A9KreqlSGqQaPMTuflFXQX2wM_SmWe-N4me0=.9b468776-17be-4860-a8fe-5615231b8b0f@github.com>

On Fri, 30 Jan 2026 12:50:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> but this is not unused/uncalled in our codebase. I think it is inlined at the 1 or 2 points were it is used. But the method is still generated into the library even in case that it is always inlined ; it may be difficult to address this with the usual linker settings on Linux (means without linktime-gc or LTO or similar stuff ) .

That is a bit unnerving but if someone were to use this warning to remove code that is used then there would be build or test failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3828786260

From acobbs at openjdk.org  Sat Jan 31 20:03:49 2026
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 31 Jan 2026 20:03:49 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v7]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <3VvHHah7TVMP4_puXRq4urxiwR8UMSJugMQ3yQZdPJo=.cae130ee-beb0-448f-87f6-a3772894f618@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 140 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Update copyrights to 2026.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159
 - Suppress new unnecessary suppresion warnings created by recent commits.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - ... and 130 more: https://git.openjdk.org/jdk/compare/6ce2f3e1...ab9af044

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=06
  Stats: 1696 lines in 35 files changed: 1494 ins; 49 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

PR: https://git.openjdk.org/jdk/pull/25167