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