From dholmes at openjdk.org  Mon Mar  3 04:55:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Mar 2025 04:55:51 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <wejMqtmaVkvy-z3h7pFXCDh4bVemMjGXoA_BWACQIkg=.59e7b61e-1a69-4370-8033-f7b172852b26@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

I agree that the call to `JNI_GetCreatedJavaVMs` serves no purpose.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23835#pullrequestreview-2653050130

From alanb at openjdk.org  Mon Mar  3 08:06:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Mar 2025 08:06:52 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <vcjJkRZ_3tEWWrUMlsW8MDnoS1jSYifSGMRFQjZql_Q=.bd0934b1-7ee7-43df-829a-00007e6a34d7@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

It was needed when the test was originally created but it has changed significantly, and the addition of Agent_OnAttach in one of the updates meant the JavaVM* is provided, no need to call JNI_GetCreatedJavaVMs anymore.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23835#pullrequestreview-2653333029

From jiangli at openjdk.org  Mon Mar  3 17:38:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 3 Mar 2025 17:38:55 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

Thanks for the reviews and historical info!

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

PR Comment: https://git.openjdk.org/jdk/pull/23835#issuecomment-2695103531

From jiangli at openjdk.org  Mon Mar  3 17:38:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 3 Mar 2025 17:38:56 GMT
Subject: Integrated: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <L9GbcUmMVIvHx8Nrb2yCNe-0hD4mEvdT0TUSS0N86-k=.1ea12469-b6a8-41d3-8b0c-21111fc3404e@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

This pull request has now been integrated.

Changeset: bb70896e
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb70896e356536477cfb770096fb769485edc55b
Stats:     10 lines in 2 files changed: 0 ins; 9 del; 1 mod

8350903: Remove explicit libjvm.so dependency for libVThreadEventTest

Reviewed-by: dholmes, alanb

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

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

From ihse at openjdk.org  Tue Mar  4 10:33:01 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Mar 2025 10:33:01 GMT
Subject: RFR: 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in
 debug builds [v2]
In-Reply-To: <l1a7R67h7fI8gE_6yJZbIlggdvARQdi05esoH6cM_AI=.78902aa4-3e8f-454e-b89a-c2b741602d89@github.com>
References: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
 <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>
 <l1a7R67h7fI8gE_6yJZbIlggdvARQdi05esoH6cM_AI=.78902aa4-3e8f-454e-b89a-c2b741602d89@github.com>
Message-ID: <UxavkaZECcDG2VYXjqYhGJfA25Qj0ndma4cOTfL2kC8=.60c1550c-218d-495c-8f21-0c722cad0903@github.com>

On Fri, 28 Feb 2025 10:28:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I think we still want this new option, but maybe there should be some way to
turn it off? Either with a configure argument explicitly, or a way for
enabling something like msan (which we don't currently support) to disable
this warning.

Let's cross that bridge when we get there. If someone actually notices problems with this flag, then they can file a JBS issue to be able to toggle it. Or if they want msan.

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

PR Comment: https://git.openjdk.org/jdk/pull/22691#issuecomment-2696981378

From ihse at openjdk.org  Tue Mar  4 10:33:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Mar 2025 10:33:02 GMT
Subject: Integrated: 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern
 in debug builds
In-Reply-To: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
References: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
Message-ID: <6q40Il3VVyRfWHyioQitI7wGXZU9A56L7L1wQtbx0wk=.05037eb9-47eb-47dc-b6a0-17a5894eb76d@github.com>

On Wed, 11 Dec 2024 21:14:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a retry to add `-ftrivial-auto-var-init=pattern` to gcc debug builds. The first attempt was buggy in multiple ways and had to be backed out.
> 
> This is the description of the original bug report:
> 
> gcc12 has added -ftrivial-auto-var-init=<choice>, which specifies how automatic variables without an initializer should be initialized. The default choice is "uninitialized", which is the default C/C++ behavior. Alternatives are "pattern" and "zero". For improved debugging, helping to detect uninitialized uses, the "pattern" choice should be used.

This pull request has now been integrated.

Changeset: fae37aaa
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
Stats:     14 lines in 4 files changed: 13 ins; 0 del; 1 mod

8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in debug builds

Reviewed-by: erikj, kbarrett

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

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

From ihse at openjdk.org  Tue Mar  4 11:36:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Mar 2025 11:36:31 GMT
Subject: RFR: 8351154: Use -ftrivial-auto-var-init=pattern for clang too
Message-ID: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>

This is a trivial (no pun intended) follow-up to [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), which just enables the -ftrivial-auto-var-init=pattern on debug builds for clang too. In contrast to gcc, the clang option did not trigger any additional warnings, so it is just about enabling the flag for debug builds.

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

Commit messages:
 - 8351154: Use -ftrivial-auto-var-init=pattern for clang too

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

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

From ihse at openjdk.org  Tue Mar  4 11:37:01 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Mar 2025 11:37:01 GMT
Subject: RFR: 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in
 debug builds [v2]
In-Reply-To: <l1a7R67h7fI8gE_6yJZbIlggdvARQdi05esoH6cM_AI=.78902aa4-3e8f-454e-b89a-c2b741602d89@github.com>
References: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
 <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>
 <l1a7R67h7fI8gE_6yJZbIlggdvARQdi05esoH6cM_AI=.78902aa4-3e8f-454e-b89a-c2b741602d89@github.com>
Message-ID: <J5aGtzXuxgl4UPUWWHSdSxja1c3-tuV3zzLn7REAR8s=.fec3d9a4-a1ad-45c2-b556-bc62a0c33a93@github.com>

On Fri, 28 Feb 2025 10:28:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Visual Studio provides a similar mechanism, InitAll.

Unfortunately, the option to enable this (`/initall`) is not officially documented, so I guess that implies that we should not use it. :-(

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

PR Comment: https://git.openjdk.org/jdk/pull/22691#issuecomment-2697220527

From kbarrett at openjdk.org  Tue Mar  4 12:26:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 4 Mar 2025 12:26:52 GMT
Subject: RFR: 8351154: Use -ftrivial-auto-var-init=pattern for clang too
In-Reply-To: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
References: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
Message-ID: <3Tg96OBVPqcbH7MN87yGQIWDGVxjKHj4ydMqfezYuow=.23648574-ec3c-433a-8650-a13027cedc70@github.com>

On Tue, 4 Mar 2025 11:31:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a trivial (no pun intended) follow-up to [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), which just enables the -ftrivial-auto-var-init=pattern on debug builds for clang too. In contrast to gcc, the clang option did not trigger any additional warnings, so it is just about enabling the flag for debug builds.

Looks good to me, but you should get the aix-ppc folks to verify there aren't any
surprises for them from turning this on.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23892#pullrequestreview-2657253001

From erikj at openjdk.org  Tue Mar  4 13:54:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Mar 2025 13:54:52 GMT
Subject: RFR: 8351154: Use -ftrivial-auto-var-init=pattern for clang too
In-Reply-To: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
References: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
Message-ID: <gwbKyrNCZvH3bM_PSklUJ5jtreC2TsfnoD3nmxfxkJU=.39a122fc-59f8-4312-9e29-34e8f53de28e@github.com>

On Tue, 4 Mar 2025 11:31:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a trivial (no pun intended) follow-up to [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), which just enables the -ftrivial-auto-var-init=pattern on debug builds for clang too. In contrast to gcc, the clang option did not trigger any additional warnings, so it is just about enabling the flag for debug builds.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23892#pullrequestreview-2657615864

From ihse at openjdk.org  Tue Mar  4 14:55:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Mar 2025 14:55:58 GMT
Subject: RFR: 8351154: Use -ftrivial-auto-var-init=pattern for clang too
In-Reply-To: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
References: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
Message-ID: <bTsKja86FMqGIEBgv9duCaZnUdB_xuGhOT0R_QZnc9E=.4c4c7a1b-6fc7-4f50-a08e-379fec59789f@github.com>

On Tue, 4 Mar 2025 11:31:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a trivial (no pun intended) follow-up to [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), which just enables the -ftrivial-auto-var-init=pattern on debug builds for clang too. In contrast to gcc, the clang option did not trigger any additional warnings, so it is just about enabling the flag for debug builds.

@MBaesken Can you or your colleagues check that this works on AIX?

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

PR Comment: https://git.openjdk.org/jdk/pull/23892#issuecomment-2697918265

From mbaesken at openjdk.org  Tue Mar  4 15:57:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Mar 2025 15:57:54 GMT
Subject: RFR: 8351154: Use -ftrivial-auto-var-init=pattern for clang too
In-Reply-To: <bTsKja86FMqGIEBgv9duCaZnUdB_xuGhOT0R_QZnc9E=.4c4c7a1b-6fc7-4f50-a08e-379fec59789f@github.com>
References: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
 <bTsKja86FMqGIEBgv9duCaZnUdB_xuGhOT0R_QZnc9E=.4c4c7a1b-6fc7-4f50-a08e-379fec59789f@github.com>
Message-ID: <-x8LLP7coXLTiNCGuqPsk_t6KwPHW696nAuvwPM091s=.42708b7c-c827-43f6-9c61-3cd603476e2b@github.com>

On Tue, 4 Mar 2025 14:53:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @MBaesken Can you or your colleagues check that this works on AIX?

A fastdebug build with the patch applied worked on AIX .

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

PR Comment: https://git.openjdk.org/jdk/pull/23892#issuecomment-2698127030

From mbaesken at openjdk.org  Tue Mar  4 16:16:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Mar 2025 16:16:03 GMT
Subject: RFR: 8350952: Remove some non present files from OPT_SPEED_SRC list
Message-ID: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>

JvmFeatures.gmk contains a file list OPT_SPEED_SRC , the list contains files that have to be optimized for speed when the other files are optimized for binary size.
However some non present files are mentioned and should be removed e.g.
genCollectedHeap.cpp
hashtable.cpp
markSweep.cpp
Maybe they were present in old releases.

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

Commit messages:
 - JDK-8350952

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

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

From syan at openjdk.org  Tue Mar  4 16:31:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Mar 2025 16:31:38 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information
Message-ID: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>

Hi all,

This PR fix the makefile bug when there is no gtest 'disable tests' then report syntax error.

Before this PR makefile used below command to get the 'disable tests' number, when there is no 'YOU HAVE [0-9]+ DISABLED TEST' string line in gtest result file gtest.txt, this gawk command will not print anything, so shell report syntax error later.


gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } if (!found) { print 0; } }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt


After this PR makefile will use below command to get the 'disable tests' number.


gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /YOU HAVE ([0-9]+) DISABLED TEST/, arr)) { print arr[1]; found=1; } } END { if (!found) print 0; }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt


Additional testing:

- [x] make test TEST=gtest:Align > test-Alian.log, which return 0 disable test
- [x] time make test TEST=gtest > test-all.log, which return 15 disable tests

[test-all.log](https://github.com/user-attachments/files/19074190/test-all.log)
[test-Alian.log](https://github.com/user-attachments/files/19074189/test-Alian.log)

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

Commit messages:
 - 8351138: Running subset of gtests gets error printing result information

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

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

From ihse at openjdk.org  Tue Mar  4 17:02:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Mar 2025 17:02:15 GMT
Subject: Integrated: 8351154: Use -ftrivial-auto-var-init=pattern for clang too
In-Reply-To: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
References: <f5rbjuVH7bxFG_VyatOFBbPJvW4kmlhh6mdeZf5vhJo=.c112854a-9898-4bf2-9f20-99718f1e1645@github.com>
Message-ID: <QgSfCftx4td1BVFpN2rllCh2Xkzuy4KBLRGEM7HCDAY=.192259ba-50a2-49dd-96cd-c0d238403c5d@github.com>

On Tue, 4 Mar 2025 11:31:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a trivial (no pun intended) follow-up to [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), which just enables the -ftrivial-auto-var-init=pattern on debug builds for clang too. In contrast to gcc, the clang option did not trigger any additional warnings, so it is just about enabling the flag for debug builds.

This pull request has now been integrated.

Changeset: 4aa4b464
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4aa4b46440dcdb0c7707cc145171a45a9f895c07
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8351154: Use -ftrivial-auto-var-init=pattern for clang too

Reviewed-by: kbarrett, erikj

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

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

From erikj at openjdk.org  Tue Mar  4 17:21:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Mar 2025 17:21:54 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information
In-Reply-To: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
Message-ID: <M8W7Ps8U3wdLKAe6ToSiUWq58fiVkm4j-P_hkHcmmn0=.89980ed0-ee54-4e6e-80e8-16778cbbb1e1@github.com>

On Tue, 4 Mar 2025 16:22:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR fix the makefile bug when there is no gtest 'disable tests' then report syntax error.
> 
> Before this PR makefile used below command to get the 'disable tests' number, when there is no 'YOU HAVE [0-9]+ DISABLED TEST' string line in gtest result file gtest.txt, this gawk command will not print anything, so shell report syntax error later.
> 
> 
> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } if (!found) { print 0; } }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
> 
> 
> After this PR makefile will use below command to get the 'disable tests' number.
> 
> 
> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /YOU HAVE ([0-9]+) DISABLED TEST/, arr)) { print arr[1]; found=1; } } END { if (!found) print 0; }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
> 
> 
> Additional testing:
> 
> - [x] make test TEST=gtest:Align > test-Alian.log, which return 0 disable test
> - [x] time make test TEST=gtest > test-all.log, which return 15 disable tests
> 
> [test-all.log](https://github.com/user-attachments/files/19074190/test-all.log)
> [test-Alian.log](https://github.com/user-attachments/files/19074189/test-Alian.log)

I haven't tested my suggestion here, but this based on how I understand awk.

make/RunTests.gmk line 543:

> 541: 	      '/YOU HAVE [0-9]+ DISABLED TEST/ { \
> 542: 	          if (match($$$$0, /YOU HAVE ([0-9]+) DISABLED TEST/, arr)) { \
> 543: 	            print arr[1]; \

I can't see how this change is needed. The block after the `/.../` regex will only be executed for lines matching the regex.

make/RunTests.gmk line 546:

> 544: 	            found=1; \
> 545: 	          } } END \
> 546: 	          { if (!found) print 0; }' \

>From what I can tell, this is the relevant fix, moving the fallback 0 to the `END` block. I would suggest reformatting this for better readability. Probably something like this. The `END` keyword should be at the same level as the regex line matcher above, though the mix of indentation levels here is a bit confusing.
Suggestion:

	          } \
	       } \
	       END { if (!found) print 0; }' \

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

PR Review: https://git.openjdk.org/jdk/pull/23904#pullrequestreview-2658383562
PR Review Comment: https://git.openjdk.org/jdk/pull/23904#discussion_r1979893492
PR Review Comment: https://git.openjdk.org/jdk/pull/23904#discussion_r1979891983

From honkar at openjdk.org  Wed Mar  5 01:03:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Mar 2025 01:03:51 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
Message-ID: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>

Harfbuzz upgraded to v10.4.0

File changes -

**Newly added files**

libharfbuzz/OT/Var/VARC/VARC.hh
libharfbuzz/OT/Var/VARC/coord-setter.hh
libharfbuzz/hb-decycler.hh
libharfbuzz/hb-geometry.hh 
libharfbuzz/hb-ot-var-varc-table.hh 
libharfbuzz/hb-subset-instancer-iup.hh  
libharfbuzz/hb-subset-serialize.h


**Deleted**

libharfbuzz/OT/glyf/VarCompositeGlyph.hh
libharfbuzz/OT/glyf/coord-setter.hh


**Modified: 182 existing files modified**

To prevent build failures due to dangling pointer on linux it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

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

Commit messages:
 - md file updated
 - md file updated
 - md file updated to 10.4.0
 - v10.3.0 to v10.4.0 changes
 - whitespace fix
 - warning section updated in gmk
 - .md file changes
 - modified files
 - newly added files
 - deleted files

Changes: https://git.openjdk.org/jdk/pull/23910/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23910&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348597
  Stats: 18558 lines in 193 files changed: 10013 ins; 2990 del; 5555 mod
  Patch: https://git.openjdk.org/jdk/pull/23910.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23910/head:pull/23910

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

From syan at openjdk.org  Wed Mar  5 02:05:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Mar 2025 02:05:15 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v2]
In-Reply-To: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
Message-ID: <Sgk4-EkXc-HUePvmom5Zei6j8BFhcDV9vS2-32EMMUs=.21baf9f8-cc49-4e16-8efd-2fb1488bf906@github.com>

> Hi all,
> 
> This PR fix the makefile bug when there is no gtest 'disable tests' then report syntax error.
> 
> Before this PR makefile used below command to get the 'disable tests' number, when there is no 'YOU HAVE [0-9]+ DISABLED TEST' string line in gtest result file gtest.txt, this gawk command will not print anything, so shell report syntax error later.
> 
> 
> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } if (!found) { print 0; } }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
> 
> 
> After this PR makefile will use below command to get the 'disable tests' number.
> 
> 
> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /YOU HAVE ([0-9]+) DISABLED TEST/, arr)) { print arr[1]; found=1; } } END { if (!found) print 0; }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
> 
> 
> Additional testing:
> 
> - [x] make test TEST=gtest:Align > test-Alian.log, which return 0 disable test
> - [x] time make test TEST=gtest > test-all.log, which return 15 disable tests
> 
> [test-all.log](https://github.com/user-attachments/files/19074190/test-all.log)
> [test-Alian.log](https://github.com/user-attachments/files/19074189/test-Alian.log)

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

  Make END keyword at the same level as the regrex line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23904/files
  - new: https://git.openjdk.org/jdk/pull/23904/files/33aef871..2c167a2a

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

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

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

From syan at openjdk.org  Wed Mar  5 02:05:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Mar 2025 02:05:15 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v2]
In-Reply-To: <M8W7Ps8U3wdLKAe6ToSiUWq58fiVkm4j-P_hkHcmmn0=.89980ed0-ee54-4e6e-80e8-16778cbbb1e1@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
 <M8W7Ps8U3wdLKAe6ToSiUWq58fiVkm4j-P_hkHcmmn0=.89980ed0-ee54-4e6e-80e8-16778cbbb1e1@github.com>
Message-ID: <_uwdzQlIagCPL2gs-PrTxHBbM_WYcEX8a1dJdBH-mJQ=.0df2bf17-8ba8-44a7-9577-3afdc7481798@github.com>

On Tue, 4 Mar 2025 17:16:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make END keyword at the same level as the regrex line
>
> make/RunTests.gmk line 546:
> 
>> 544: 	            found=1; \
>> 545: 	          } } END \
>> 546: 	          { if (!found) print 0; }' \
> 
> From what I can tell, this is the relevant fix, moving the fallback 0 to the `END` block. I would suggest reformatting this for better readability. Probably something like this. The `END` keyword should be at the same level as the regex line matcher above, though the mix of indentation levels here is a bit confusing.
> Suggestion:
> 
> 	          } \
> 	       } \
> 	       END { if (!found) print 0; }' \

Thanks, END keyword has been change to at the same level as the regrex line

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23904#discussion_r1980549314

From syan at openjdk.org  Wed Mar  5 02:10:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Mar 2025 02:10:34 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v3]
In-Reply-To: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
Message-ID: <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>

> Hi all,
> 
> This PR fix the makefile bug when there is no gtest 'disable tests' then report syntax error.
> 
> Before this PR makefile used below command to get the 'disable tests' number, when there is no 'YOU HAVE [0-9]+ DISABLED TEST' string line in gtest result file gtest.txt, this gawk command will not print anything, so shell report syntax error later.
> 
> 
> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } if (!found) { print 0; } }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
> 
> 
> After this PR makefile will use below command to get the 'disable tests' number.
> 
> 
> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /YOU HAVE ([0-9]+) DISABLED TEST/, arr)) { print arr[1]; found=1; } } END { if (!found) print 0; }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
> 
> 
> Additional testing:
> 
> - [x] make test TEST=gtest:Align > test-Alian.log, which return 0 disable test
> - [x] time make test TEST=gtest > test-all.log, which return 15 disable tests
> 
> [test-all.log](https://github.com/user-attachments/files/19074190/test-all.log)
> [test-Alian.log](https://github.com/user-attachments/files/19074189/test-Alian.log)

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

  Revert regex change in if expr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23904/files
  - new: https://git.openjdk.org/jdk/pull/23904/files/2c167a2a..f798204c

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

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

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

From syan at openjdk.org  Wed Mar  5 02:10:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Mar 2025 02:10:34 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v3]
In-Reply-To: <M8W7Ps8U3wdLKAe6ToSiUWq58fiVkm4j-P_hkHcmmn0=.89980ed0-ee54-4e6e-80e8-16778cbbb1e1@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
 <M8W7Ps8U3wdLKAe6ToSiUWq58fiVkm4j-P_hkHcmmn0=.89980ed0-ee54-4e6e-80e8-16778cbbb1e1@github.com>
Message-ID: <w-hIvkOkzUW8Yta1YuAW91Q_JdrOnPdVJAucJbQ7Hwk=.74c2d8e2-2bc9-45bc-ad35-b9fc6f3cb218@github.com>

On Tue, 4 Mar 2025 17:17:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert regex change in if expr
>
> make/RunTests.gmk line 543:
> 
>> 541: 	      '/YOU HAVE [0-9]+ DISABLED TEST/ { \
>> 542: 	          if (match($$$$0, /YOU HAVE ([0-9]+) DISABLED TEST/, arr)) { \
>> 543: 	            print arr[1]; \
> 
> I can't see how this change is needed. The block after the `/.../` regex will only be executed for lines matching the regex.

You are right, these two line change has been reverted. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23904#discussion_r1980555286

From dholmes at openjdk.org  Wed Mar  5 05:46:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Mar 2025 05:46:56 GMT
Subject: RFR: 8350952: Remove some non present files from OPT_SPEED_SRC
 list
In-Reply-To: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
References: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
Message-ID: <mO4ILcypI6CuKDlEFSZOJ61N1y5b4LtsvlIPkOTcaxI=.46161b4b-0cf4-42d9-b5b9-334212097494@github.com>

On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> JvmFeatures.gmk contains a file list OPT_SPEED_SRC , the list contains files that have to be optimized for speed when the other files are optimized for binary size.
> However some non present files are mentioned and should be removed e.g.
> genCollectedHeap.cpp
> hashtable.cpp
> markSweep.cpp
> Maybe they were present in old releases.

LGTM.

Yes these files once existed but have since been replaced or deleted.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23902#pullrequestreview-2659995393

From syan at openjdk.org  Wed Mar  5 07:26:27 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Mar 2025 07:26:27 GMT
Subject: RFR: 8351241: Require minimum gcc version 12
Message-ID: <St3WKpotBBQAI9gTQH4llgZ2BORdS1p1PZcoSXLUdMw=.6fb1f742-f755-4c0a-b194-aed615874781@github.com>

Hi all,

After [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), the minumum gcc version should be 12. [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627) add gcc compile option -ftrivial-auto-var-init=pattern for debug build, -ftrivial-auto-var-init=pattern gcc option was supported since [gcc12](https://gcc.gnu.org/gcc-12/changes.html#uninitialized).

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

Commit messages:
 - 8351241: Require minimum gcc version 12

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

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

From dholmes at openjdk.org  Wed Mar  5 07:35:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Mar 2025 07:35:15 GMT
Subject: RFR: 8351241: Require minimum gcc version 12
In-Reply-To: <St3WKpotBBQAI9gTQH4llgZ2BORdS1p1PZcoSXLUdMw=.6fb1f742-f755-4c0a-b194-aed615874781@github.com>
References: <St3WKpotBBQAI9gTQH4llgZ2BORdS1p1PZcoSXLUdMw=.6fb1f742-f755-4c0a-b194-aed615874781@github.com>
Message-ID: <bz7LGMqn6CUuoH5zxnmbcX9Fl3WpTFZfVMDMwBV4Y3M=.b183991d-57c2-4175-8cb6-719244150932@github.com>

On Wed, 5 Mar 2025 07:21:17 GMT, SendaoYan <syan at openjdk.org> wrote:

> After [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), the minumum gcc version should be 12

Or JDK-8345627 change should only be enabled when gcc version is >= 12.

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

PR Comment: https://git.openjdk.org/jdk/pull/23913#issuecomment-2700093818

From syan at openjdk.org  Wed Mar  5 07:57:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Mar 2025 07:57:51 GMT
Subject: RFR: 8351241: Require minimum gcc version 12
In-Reply-To: <bz7LGMqn6CUuoH5zxnmbcX9Fl3WpTFZfVMDMwBV4Y3M=.b183991d-57c2-4175-8cb6-719244150932@github.com>
References: <St3WKpotBBQAI9gTQH4llgZ2BORdS1p1PZcoSXLUdMw=.6fb1f742-f755-4c0a-b194-aed615874781@github.com>
 <bz7LGMqn6CUuoH5zxnmbcX9Fl3WpTFZfVMDMwBV4Y3M=.b183991d-57c2-4175-8cb6-719244150932@github.com>
Message-ID: <pCKJd9WnHVvColpuXaKKpQJEo-qXdnBnLV0v1xd8lfo=.8e1fd151-cfce-4e3e-a88f-09d1d409265e@github.com>

On Wed, 5 Mar 2025 07:32:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > After [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), the minumum gcc version should be 12
> 
> Or JDK-8345627 change should only be enabled when gcc version is >= 12.

JDK-8345627 has already check the gcc compiler support -ftrivial-auto-var-init=pattern or not by macro function FLAGS_COMPILER_CHECK_ARGUMENTS. If the gcc do not support -ftrivial-auto-var-init=pattern option, this option will not take effect during configure.

So it's not a issue actually?

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

PR Comment: https://git.openjdk.org/jdk/pull/23913#issuecomment-2700136712

From mbaesken at openjdk.org  Wed Mar  5 08:43:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Mar 2025 08:43:56 GMT
Subject: RFR: 8350952: Remove some non present files from OPT_SPEED_SRC
 list
In-Reply-To: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
References: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
Message-ID: <oEzOBwg87nYG_-mBDYKZnlX3r2mw_-aLd6M27qvdR7Y=.d569213d-c341-467a-82b2-2494e4763441@github.com>

On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> JvmFeatures.gmk contains a file list OPT_SPEED_SRC , the list contains files that have to be optimized for speed when the other files are optimized for binary size.
> However some non present files are mentioned and should be removed e.g.
> genCollectedHeap.cpp
> hashtable.cpp
> markSweep.cpp
> Maybe they were present in old releases.

Hi David, thanks for the review !
I wonder how useful this OPT_SPEED_SRC list is these days ; from what I heard it was setup a long time ago and also some tests/benchmarks were done back then. But in the meantime probably a lot of new files were added to the hs codebase that are also performance sensitive.
On the other hand , the compilers were switched a few times between introduction of the OPT_SPEED_SRC  list and now, so  who knows how valid the list is even for the files in it currently.

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

PR Comment: https://git.openjdk.org/jdk/pull/23902#issuecomment-2700234710

From clanger at openjdk.org  Wed Mar  5 10:27:57 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 5 Mar 2025 10:27:57 GMT
Subject: RFR: 8350952: Remove some non present files from OPT_SPEED_SRC
 list
In-Reply-To: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
References: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
Message-ID: <eITsUtBm077Ulz82Y_rz66R_HdZj-iEvZ7GzUvgDab8=.c8f7df82-8186-4b68-b4df-b77dc6387a2d@github.com>

On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> JvmFeatures.gmk contains a file list OPT_SPEED_SRC , the list contains files that have to be optimized for speed when the other files are optimized for binary size.
> However some non present files are mentioned and should be removed e.g.
> genCollectedHeap.cpp
> hashtable.cpp
> markSweep.cpp
> Maybe they were present in old releases.

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23902#pullrequestreview-2660656842

From mbaesken at openjdk.org  Wed Mar  5 12:33:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Mar 2025 12:33:00 GMT
Subject: RFR: 8350952: Remove some non present files from OPT_SPEED_SRC
 list
In-Reply-To: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
References: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
Message-ID: <KHYe8AelPjpVQNXWgvS24Hes7JfkeIQsKpmyrhoP2No=.eae4508c-30f1-4317-890f-9f705dcaf1cd@github.com>

On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> JvmFeatures.gmk contains a file list OPT_SPEED_SRC , the list contains files that have to be optimized for speed when the other files are optimized for binary size.
> However some non present files are mentioned and should be removed e.g.
> genCollectedHeap.cpp
> hashtable.cpp
> markSweep.cpp
> Maybe they were present in old releases.

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23902#issuecomment-2700794146

From mbaesken at openjdk.org  Wed Mar  5 12:33:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Mar 2025 12:33:00 GMT
Subject: Integrated: 8350952: Remove some non present files from OPT_SPEED_SRC
 list
In-Reply-To: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
References: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
Message-ID: <gtLB5SCPLXMQa5bjliyvUKwX8Flcc9TzpKrCqi-fkbA=.0dc2d744-7fc2-4ee1-9dac-2834d7b83423@github.com>

On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> JvmFeatures.gmk contains a file list OPT_SPEED_SRC , the list contains files that have to be optimized for speed when the other files are optimized for binary size.
> However some non present files are mentioned and should be removed e.g.
> genCollectedHeap.cpp
> hashtable.cpp
> markSweep.cpp
> Maybe they were present in old releases.

This pull request has now been integrated.

Changeset: a88e8cd0
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a88e8cd0d2a444187208b41875b9da45daadad6a
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8350952: Remove some non present files from OPT_SPEED_SRC list

Reviewed-by: dholmes, clanger

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

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

From erikj at openjdk.org  Wed Mar  5 14:11:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Mar 2025 14:11:51 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <1Lkzsid1vE9sXmyoP-6_2FJN9RUkOJEKbrYdLVTHIAI=.b26c3b8d-13f7-45fe-b20b-00fac416b2ee@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

Build change looks ok.

The clang users on Linux may want to check if the same new warning triggers there.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23910#pullrequestreview-2661239964

From erikj at openjdk.org  Wed Mar  5 14:12:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Mar 2025 14:12:58 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v3]
In-Reply-To: <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
 <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>
Message-ID: <4TNkmn7EQo0ptD0or5DagwYjdjRvnbpPTXGJZyE6D4Y=.4bdd7cf7-b21e-4c40-8ad6-ea96086c017b@github.com>

On Wed, 5 Mar 2025 02:10:34 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR fix the makefile bug when there is no gtest 'disable tests' then report syntax error.
>> 
>> Before this PR makefile used below command to get the 'disable tests' number, when there is no 'YOU HAVE [0-9]+ DISABLED TEST' string line in gtest result file gtest.txt, this gawk command will not print anything, so shell report syntax error later.
>> 
>> 
>> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } if (!found) { print 0; } }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
>> 
>> 
>> After this PR makefile will use below command to get the 'disable tests' number.
>> 
>> 
>> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } } END { if (!found) print 0; }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
>> 
>> 
>> Additional testing:
>> 
>> - [x] make test TEST=gtest:Align > test-Alian.log, which return 0 disable test
>> - [x] time make test TEST=gtest > test-all.log, which return 15 disable tests
>> 
>> [test-all.log](https://github.com/user-attachments/files/19074190/test-all.log)
>> [test-Alian.log](https://github.com/user-attachments/files/19074189/test-Alian.log)
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert regex change in if expr

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23904#pullrequestreview-2661243123

From erikj at openjdk.org  Wed Mar  5 14:15:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Mar 2025 14:15:51 GMT
Subject: RFR: 8351241: Require minimum gcc version 12
In-Reply-To: <pCKJd9WnHVvColpuXaKKpQJEo-qXdnBnLV0v1xd8lfo=.8e1fd151-cfce-4e3e-a88f-09d1d409265e@github.com>
References: <St3WKpotBBQAI9gTQH4llgZ2BORdS1p1PZcoSXLUdMw=.6fb1f742-f755-4c0a-b194-aed615874781@github.com>
 <bz7LGMqn6CUuoH5zxnmbcX9Fl3WpTFZfVMDMwBV4Y3M=.b183991d-57c2-4175-8cb6-719244150932@github.com>
 <pCKJd9WnHVvColpuXaKKpQJEo-qXdnBnLV0v1xd8lfo=.8e1fd151-cfce-4e3e-a88f-09d1d409265e@github.com>
Message-ID: <wiLJaF8lNEkcWKYtIJGY6kNwGyZxLgyFgpVHeOKWctE=.4912c895-5a33-4df7-8b16-0bff38ae442e@github.com>

On Wed, 5 Mar 2025 07:54:51 GMT, SendaoYan <syan at openjdk.org> wrote:

> > > After [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), the minumum gcc version should be 12
> > 
> > 
> > Or JDK-8345627 change should only be enabled when gcc version is >= 12.
> 
> JDK-8345627 has already check the gcc compiler support -ftrivial-auto-var-init=pattern or not by macro function FLAGS_COMPILER_CHECK_ARGUMENTS. If the gcc do not support -ftrivial-auto-var-init=pattern option, this option will not take effect during configure.
> 
> So it's not a issue actually?

It shouldn't be, unless you have actually tried building the JDK with a lower version and it failed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23913#issuecomment-2701065029

From shade at openjdk.org  Wed Mar  5 16:55:25 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Mar 2025 16:55:25 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
Message-ID: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>

This PR implements JEP 503: Remove the 32-bit x86 Port.

The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.

This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.

The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.

Additional testing:
 - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
 - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
 - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
 - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

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

Commit messages:
 - Generic 32-bit x86 configure error supercedes Windows 32-bit x86
 - 8345169: Implement JEP 503: Remove the 32-bit x86 Port

Changes: https://git.openjdk.org/jdk/pull/23906/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23906&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345169
  Stats: 30068 lines in 26 files changed: 4 ins; 30054 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23906/head:pull/23906

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

From vlivanov at openjdk.org  Wed Mar  5 17:19:13 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 5 Mar 2025 17:19:13 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <xXkwvrzNwbvDmvPWkfXtYEgTJNN24MKDK7gB22wqGqY=.d2b48bc2-a06d-4923-82cc-2c3e17042fdd@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

Hotspot changes look good to me. 

I fully support removing x86-32-specific files first and then clean up x86-32-specific code in x86-specific and shared files (e.g., guarded by `#ifndef _LP64`).

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2661836831

From honkar at openjdk.org  Wed Mar  5 19:04:59 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Mar 2025 19:04:59 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <_zgC1NLNsTUH7R25xkfGEfh0f2IOJllcUFjvrBeY7ig=.7c026edc-a5f6-46e7-a480-ef8614feacf6@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

src/java.desktop/share/native/libharfbuzz/hb.hh line 134:

> 132: #pragma GCC diagnostic ignored "-Wcast-function-type-strict" // https://github.com/harfbuzz/harfbuzz/pull/3859#issuecomment-1295409126
> 133: #pragma GCC diagnostic ignored "-Wdangling-reference" // https://github.com/harfbuzz/harfbuzz/issues/4043
> 134: #pragma GCC diagnostic ignored "-Wdangling-pointer" // Trigerred by hb_decycler_node_t().

@prrace With the latest harfbuzz (v10.4.0), dangling-pointer warning is ignored. With this addition, I assumed that we no longer need to add it to harfbuzz warning section explicitly. 

But without adding dangling-pointer to `HARFBUZZ_DISABLED_WARNINGS_gcc` build fails on linux so probably JDK build requires warnings to be explicitly added to ClientLibraries.gmk ?


decycler.hh:110:25: error: storing the address of local variable ?decycler_node'
 in '((hb_decycler_t*)((char*)scratch + 8))[1].hb_decycler_t::tortoise' [-Werror=dangling-pointer=]
  110 |       decycler.tortoise = decycler.hare = this;
      |       ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23910#discussion_r1982033388

From kvn at openjdk.org  Wed Mar  5 20:10:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 5 Mar 2025 20:10:53 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <jeqdGTfk6-Y6uRSo3ZYDpU8OfOwUIXK9uXMIvS6hLfA=.489509c3-3985-4d1a-ad42-4c1214d40eb3@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

Good.

So it will be stacked PRs which you will combine for final integration?

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2662377172

From kvn at openjdk.org  Wed Mar  5 20:14:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 5 Mar 2025 20:14:53 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <8UpKLmwCBMscNGtKyktL_h1aBYo6uzB3kYJOWeJIugA=.78c737ec-e212-4458-a009-79867ad260e5@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

This is confusing. This PR is part of changes so it can't be "Implement JEP 503: Remove the 32-bit x86 Port" and should be subtask of Umbrella RFE.
Am I missing something?

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2701962563

From prr at openjdk.org  Wed Mar  5 20:18:55 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 20:18:55 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <47x-CN3ZcoOHt0rkLBnoWGqN5WgRqng0oHra1AL4Gpc=.1a9274b8-ad40-4958-88c9-f1df68d00fb0@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

src/java.desktop/share/native/libharfbuzz/UPDATING.txt line 56:

> 54: STEP 3: COMPILER WARNINGS AND SETTING FLAGS
> 55: -------------------------------------------
> 56: - Update make parameters in make/modules/java.desktop/lib/ClientLibraries.gmk

good catch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23910#discussion_r1980742878

From prr at openjdk.org  Wed Mar  5 20:18:56 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 20:18:56 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <_zgC1NLNsTUH7R25xkfGEfh0f2IOJllcUFjvrBeY7ig=.7c026edc-a5f6-46e7-a480-ef8614feacf6@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
 <_zgC1NLNsTUH7R25xkfGEfh0f2IOJllcUFjvrBeY7ig=.7c026edc-a5f6-46e7-a480-ef8614feacf6@github.com>
Message-ID: <C_jtsYDvOghWkIhfO1FLfje4Vcg4c7PAtc1eWISHz4Q=.ce9fdef6-b1b0-48a4-b054-01ee48a57f69@github.com>

On Wed, 5 Mar 2025 19:00:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Harfbuzz upgraded to v10.4.0
>> 
>> File changes -
>> 
>> **Newly added files**
>> 
>> libharfbuzz/OT/Var/VARC/VARC.hh
>> libharfbuzz/OT/Var/VARC/coord-setter.hh
>> libharfbuzz/hb-decycler.hh
>> libharfbuzz/hb-geometry.hh 
>> libharfbuzz/hb-ot-var-varc-table.hh 
>> libharfbuzz/hb-subset-instancer-iup.hh  
>> libharfbuzz/hb-subset-serialize.h
>> 
>> 
>> **Deleted**
>> 
>> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
>> libharfbuzz/OT/glyf/coord-setter.hh
>> 
>> 
>> **Modified: 182 existing files modified**
>> 
>> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)
>
> src/java.desktop/share/native/libharfbuzz/hb.hh line 134:
> 
>> 132: #pragma GCC diagnostic ignored "-Wcast-function-type-strict" // https://github.com/harfbuzz/harfbuzz/pull/3859#issuecomment-1295409126
>> 133: #pragma GCC diagnostic ignored "-Wdangling-reference" // https://github.com/harfbuzz/harfbuzz/issues/4043
>> 134: #pragma GCC diagnostic ignored "-Wdangling-pointer" // Trigerred by hb_decycler_node_t().
> 
> @prrace With the latest harfbuzz (v10.4.0), dangling-pointer warning is ignored. With this addition, I assumed that we no longer need to add it to harfbuzz warning section explicitly. 
> 
> But without adding dangling-pointer to `HARFBUZZ_DISABLED_WARNINGS_gcc` build fails on linux so probably JDK build requires warnings to be explicitly added to ClientLibraries.gmk ?
> 
> 
> decycler.hh:110:25: error: storing the address of local variable ?decycler_node'
>  in '((hb_decycler_t*)((char*)scratch + 8))[1].hb_decycler_t::tortoise' [-Werror=dangling-pointer=]
>   110 |       decycler.tortoise = decycler.hare = this;
>       |       ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

Interesting. I also would have expected this to over-ride the JDK default.
But if that's what you see ... 
A bit  of googling suggests that sometimes these pragmas are read too late.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23910#discussion_r1982127430

From prr at openjdk.org  Wed Mar  5 20:35:57 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Mar 2025 20:35:57 GMT
Subject: RFR: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <l7q5tu82tEipF6ZzRnEIv-XzSsMFmhqIsdVV5HJFBDo=.4ed768fb-9ca2-43f6-b520-0b41a94a5cc1@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

I had to use webrev to review. github was too painfully slow.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23910#pullrequestreview-2662424045

From duke at openjdk.org  Wed Mar  5 21:52:25 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Wed, 5 Mar 2025 21:52:25 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
Message-ID: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>

Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
This allows various editors to easily infer basics of the coding style.

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

Commit messages:
 - add editorconfig for better indentation detection

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

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

From jiangli at openjdk.org  Wed Mar  5 23:04:25 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 5 Mar 2025 23:04:25 GMT
Subject: RFR: 8351309: test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java
 fails on static-jdk
Message-ID: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>

Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

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

Commit messages:
 - Filter out libjsig by default for static JDK.

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

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

From vlivanov at openjdk.org  Wed Mar  5 23:22:51 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 5 Mar 2025 23:22:51 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

There's a wide variety of options to justify the goal of the JEP. A bare minimum would be to just remove x86-32 build support. And on the other side of the spectrum the current patch would be accompanied by all x86-32-specific code and all the features used exclusively by x86-32 port.

During previous round of discussions I expressed my preference as keeping JEP implementation simple and perform all non-trivial cleanups as follow-up RFEs. IMO it enables swift removal (and eliminates the burden to keep x86-32 port alive during ongoing development work) while keeping incremental cleanup activities at comfortable pace. 

Proposed patch perfectly justifies my preference.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702299307

From kvn at openjdk.org  Wed Mar  5 23:35:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 5 Mar 2025 23:35:54 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <5ztalawYQsCNUsfzWyR_b5YVFWbDNzoHVUA4ycRjvRs=.42fd2b02-462f-4803-9d3b-2b907121c5be@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

To clarify. I am completely agree with changes in this PR - I approved it.

My concern is the **Title** of this PR and JBS entry.  So I want to understand the steps we do with this PR and following changes covered by numbers of subtask pointed by Aleksey.

So what, @iwanowww, you say is that this PR is **indeed** implementation of the JEP.
And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP.

Do I understand that correctly?

Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702316448

From vlivanov at openjdk.org  Thu Mar  6 00:18:52 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 6 Mar 2025 00:18:52 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com>
Message-ID: <xKHhFYIxvCv8mkElhDeTpHcor35FkV9QdWLI0qY_SQc=.1b97dabc-fa7d-4940-bdfa-4e4915901c35@github.com>

On Wed, 5 Mar 2025 23:19:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>> 
>> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
>> 
>> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
>> 
>> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
>
> There's a wide variety of options to justify the goal of the JEP. A bare minimum would be to just remove x86-32 build support. And on the other side of the spectrum the current patch would be accompanied by all x86-32-specific code and all the features used exclusively by x86-32 port.
> 
> During previous round of discussions I expressed my preference as keeping JEP implementation simple and perform all non-trivial cleanups as follow-up RFEs. IMO it enables swift removal (and eliminates the burden to keep x86-32 port alive during ongoing development work) while keeping incremental cleanup activities at comfortable pace. 
> 
> Proposed patch perfectly justifies my preference.

> So what, @iwanowww, you say is that this PR is indeed implementation of the JEP.
> And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP.
> Do I understand that correctly?

Yes.

> Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push.

It's definitely an option. But, most likely, there'll be some overlooked cases anyway (leading to additional followup RFEs). And the more convoluted the changes are the harder it is to validate their correctness, thus increasing the risks for product stability and delaying the integration. (I'm not sure how much time Aleksey and other contributors want to volunteer to this project.)  

Also, in case of AOT JEP the situation was quite the opposite: it started with a huge patch which was split into multiple mostly independent parts to streamline its review. For x86-32 code removal there's no such patch prepared yet and the complete scope of work is not clear yet.  

IMO the crucial part is to get the port officially retired. After that the rest can become a good source of starter tasks :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702376289

From kvn at openjdk.org  Thu Mar  6 00:21:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 6 Mar 2025 00:21:53 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <SBEj8yHFEZxXYpAbgXXUZDqhwKidorGWjBnUjf3jwHE=.b24a2faf-9e66-4300-b111-98d6571b5a3a@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

Okay. Thank you for explaining.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702380269

From syan at openjdk.org  Thu Mar  6 01:43:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 01:43:58 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v3]
In-Reply-To: <4TNkmn7EQo0ptD0or5DagwYjdjRvnbpPTXGJZyE6D4Y=.4bdd7cf7-b21e-4c40-8ad6-ea96086c017b@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
 <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>
 <4TNkmn7EQo0ptD0or5DagwYjdjRvnbpPTXGJZyE6D4Y=.4bdd7cf7-b21e-4c40-8ad6-ea96086c017b@github.com>
Message-ID: <X5_T2W7WfR0HHk1-56XGtop1jOLdkc2w2EniUOnRReQ=.5afdce10-f0da-4a19-9f67-492e5d37eeb1@github.com>

On Wed, 5 Mar 2025 14:10:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert regex change in if expr
>
> Marked as reviewed by erikj (Reviewer).

Thanks @erikj79  for the reviews and suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/23904#issuecomment-2702506844

From syan at openjdk.org  Thu Mar  6 01:43:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 01:43:58 GMT
Subject: Integrated: 8351138: Running subset of gtests gets error printing
 result information
In-Reply-To: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
Message-ID: <dZ87fA3aM9NSiNpLSzeqv9BA41Evl_UoGU7uV4X9KO0=.e8ce379d-6a36-4455-bab7-b1e056a47036@github.com>

On Tue, 4 Mar 2025 16:22:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR fix the makefile bug when there is no gtest 'disable tests' then report syntax error.
> 
> Before this PR makefile used below command to get the 'disable tests' number, when there is no 'YOU HAVE [0-9]+ DISABLED TEST' string line in gtest result file gtest.txt, this gawk command will not print anything, so shell report syntax error later.
> 
> 
> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } if (!found) { print 0; } }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
> 
> 
> After this PR makefile will use below command to get the 'disable tests' number.
> 
> 
> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } } END { if (!found) print 0; }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
> 
> 
> Additional testing:
> 
> - [x] make test TEST=gtest:Align > test-Alian.log, which return 0 disable test
> - [x] time make test TEST=gtest > test-all.log, which return 15 disable tests
> 
> [test-all.log](https://github.com/user-attachments/files/19074190/test-all.log)
> [test-Alian.log](https://github.com/user-attachments/files/19074189/test-Alian.log)

This pull request has now been integrated.

Changeset: 4bb3d814
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4bb3d81479c1bbe2c6fc7b5234d0f1b6897be117
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8351138: Running subset of gtests gets error printing result information

Reviewed-by: erikj

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

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

From syan at openjdk.org  Thu Mar  6 01:52:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 01:52:57 GMT
Subject: RFR: 8351241: Require minimum gcc version 12
In-Reply-To: <wiLJaF8lNEkcWKYtIJGY6kNwGyZxLgyFgpVHeOKWctE=.4912c895-5a33-4df7-8b16-0bff38ae442e@github.com>
References: <St3WKpotBBQAI9gTQH4llgZ2BORdS1p1PZcoSXLUdMw=.6fb1f742-f755-4c0a-b194-aed615874781@github.com>
 <bz7LGMqn6CUuoH5zxnmbcX9Fl3WpTFZfVMDMwBV4Y3M=.b183991d-57c2-4175-8cb6-719244150932@github.com>
 <pCKJd9WnHVvColpuXaKKpQJEo-qXdnBnLV0v1xd8lfo=.8e1fd151-cfce-4e3e-a88f-09d1d409265e@github.com>
 <wiLJaF8lNEkcWKYtIJGY6kNwGyZxLgyFgpVHeOKWctE=.4912c895-5a33-4df7-8b16-0bff38ae442e@github.com>
Message-ID: <AsO95EMa28daojYAocQqrGyQAL3ZHKW2nbWOoYxMmr4=.d3c99fdb-56ae-443f-acc1-3b3b48f8ed1d@github.com>

On Wed, 5 Mar 2025 14:12:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> It shouldn't be, unless you have actually tried building the JDK with a lower version and it failed.

I do obscene building jdk failure after [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627) with gcc14(riscv cross compiler) and gcc10(native compiler) which recorded by [JDK-8351263](https://bugs.openjdk.org/browse/JDK-8351263). But I think we should close this PR as 'not an issue'.

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

PR Comment: https://git.openjdk.org/jdk/pull/23913#issuecomment-2702516715

From syan at openjdk.org  Thu Mar  6 01:52:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 01:52:58 GMT
Subject: Withdrawn: 8351241: Require minimum gcc version 12
In-Reply-To: <St3WKpotBBQAI9gTQH4llgZ2BORdS1p1PZcoSXLUdMw=.6fb1f742-f755-4c0a-b194-aed615874781@github.com>
References: <St3WKpotBBQAI9gTQH4llgZ2BORdS1p1PZcoSXLUdMw=.6fb1f742-f755-4c0a-b194-aed615874781@github.com>
Message-ID: <xuVI4YwebEREMJiprbH4TDesJGpofIIfBlvYo10j1zE=.4882f808-465c-48a6-99b0-430e4f2a2f2a@github.com>

On Wed, 5 Mar 2025 07:21:17 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> After [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627), the minumum gcc version should be 12. [JDK-8345627](https://bugs.openjdk.org/browse/JDK-8345627) add gcc compile option -ftrivial-auto-var-init=pattern for debug build, -ftrivial-auto-var-init=pattern gcc option was supported since [gcc12](https://gcc.gnu.org/gcc-12/changes.html#uninitialized).

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Thu Mar  6 04:38:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 04:38:52 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <jHiYGG2UeGC9r4pcM7d_NNiyozx-B7htKeqFPuChCr4=.71084493-fdfd-485e-bc5b-d221a4827156@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

I am also a bit puzzled by the JEP/JBS strategy here. I would expect a bunch of dependent PRs that then get integrated together as "The Implementation of JEP 503". I understand things may be missed that require some follow up RFE's but I don't think we should start from that position and have a large chunk of work not be done under the JEP umbrella.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702781694

From dholmes at openjdk.org  Thu Mar  6 05:53:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 05:53:57 GMT
Subject: RFR: 8350952: Remove some non present files from OPT_SPEED_SRC
 list
In-Reply-To: <oEzOBwg87nYG_-mBDYKZnlX3r2mw_-aLd6M27qvdR7Y=.d569213d-c341-467a-82b2-2494e4763441@github.com>
References: <ZR0oIf3oI8x8UQZfPhplUiCzC5Ruw4sz4r-C0iuqaec=.c9cb4ff2-7785-41b7-8f99-cbe045cd7741@github.com>
 <oEzOBwg87nYG_-mBDYKZnlX3r2mw_-aLd6M27qvdR7Y=.d569213d-c341-467a-82b2-2494e4763441@github.com>
Message-ID: <piGsyYnCgads--YXYmWIFkggvC3lgw9XnFgpRwv9Tw0=.cbee3013-5ebc-478d-b309-deebd1421ac1@github.com>

On Wed, 5 Mar 2025 08:41:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I wonder how useful this OPT_SPEED_SRC list is these days 

I suspect not useful at all. Too much has changed. This kind of list should be examined each time we update a toolchain. And in principle any new file should be evaluated to see if needs to be included.

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

PR Comment: https://git.openjdk.org/jdk/pull/23902#issuecomment-2702879127

From manc at openjdk.org  Thu Mar  6 05:58:53 2025
From: manc at openjdk.org (Man Cao)
Date: Thu, 6 Mar 2025 05:58:53 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <7xslrGte187xJy22qg_3aY5Cwx-dwEumw5hGaYXhSzk=.95d0c93a-d812-48de-a276-a1939ac2f407@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

This LGTM. Perhaps wait for another approval from a reviewer?

libjsig is not supposed to be enabled by default. Per [Java 23 doc](https://docs.oracle.com/en/java/javase/23/troubleshoot/handle-signals-and-exceptions.html#GUID-CB49A2A7-2A9F-4C18-948F-6D4A96FF688D), it is user's choice whether to use libjsig.so. If they use it, they should either link the application with linker flag `-ljsig`, or use LD_PRELOAD.

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

Marked as reviewed by manc (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23924#pullrequestreview-2663405583

From shade at openjdk.org  Thu Mar  6 09:52:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Mar 2025 09:52:09 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <xKHhFYIxvCv8mkElhDeTpHcor35FkV9QdWLI0qY_SQc=.1b97dabc-fa7d-4940-bdfa-4e4915901c35@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com>
 <xKHhFYIxvCv8mkElhDeTpHcor35FkV9QdWLI0qY_SQc=.1b97dabc-fa7d-4940-bdfa-4e4915901c35@github.com>
Message-ID: <vc_8BUQmGlQ49NItxWj8XCcs-NyifesE-ZqOYVGF8t8=.a345a768-d087-402a-bbb2-91430778573c@github.com>

On Thu, 6 Mar 2025 00:16:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> There's a wide variety of options to justify the goal of the JEP. A bare minimum would be to just remove x86-32 build support. And on the other side of the spectrum the current patch would be accompanied by all x86-32-specific code and all the features used exclusively by x86-32 port.
>> 
>> During previous round of discussions I expressed my preference as keeping JEP implementation simple and perform all non-trivial cleanups as follow-up RFEs. IMO it enables swift removal (and eliminates the burden to keep x86-32 port alive during ongoing development work) while keeping incremental cleanup activities at comfortable pace. 
>> 
>> Proposed patch perfectly justifies my preference.
>
>> So what, @iwanowww, you say is that this PR is indeed implementation of the JEP.
>> And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP.
>> Do I understand that correctly?
> 
> Yes.
> 
>> Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push.
> 
> It's definitely an option. But, most likely, there'll be some overlooked cases anyway (leading to additional followup RFEs). And the more convoluted the changes are the harder it is to validate their correctness, thus increasing the risks for product stability and delaying the integration. (I'm not sure how much time Aleksey and other contributors want to volunteer to this project.)  
> 
> Also, in case of AOT JEP the situation was quite the opposite: it started with a huge patch which was split into multiple mostly independent parts to streamline its review. For x86-32 code removal there's no such patch prepared yet and the complete scope of work is not clear yet.  
> 
> IMO the crucial part is to get the port officially retired. After that the rest can become a good source of starter tasks :-)

Basically what @iwanowww said: this PR *is* the removal of x86_32 port.

After this PR integrates, it is not possible to build x86_32, because the core implementation of it is missing, and build system would refuse to even try building it. So this removes x86_32 port as the feature, atomically, matching the title and intent of the JEP. *Then*, follow-up subtasks RFE would clean up the parts of Hotspot that were added to support various x86_32-specific features, and are no longer needed anymore.

I, for one, also believed the complete PR would be more straight-forward. I attempted this at at https://github.com/openjdk/jdk/pull/22567. After working on that draft PR, and listening to what people said about it, I can conclude that is not a great way to go with this removal.

The massive drawbacks of complete/stacked PR are now obvious to me:
  1. It is hard to review. The complete PR is huge, 210+ files affected. A lot of removals are logically connected across different files, and while they are simple in isolation, it is hard for a reviewer to separate several cleanups in large PRs.
  2. It accrues merge conflicts very fast. This happens even when mainline is somewhat idle without large feature integrations. I expect this work to be even harder once we are closer to RDP1. 
  3. It is hard to reach consensus on. Non-trivial changes require thorough review, and cobbling together multiple non-trivial changes require polynomially more coordination. I have seen this in Win32 port removal, so for a large PR like that I expect multiple, week-long review and amendment sessions. Which conspires with (1) and (2).
  4. It is easy to introduce/overlook bugs. I already did this once in a complete PR when I accidentally removed the wrong part of C1 regalloc code, and it started ever so slightly misbehaving. And it was not obvious, because it was obscured by other changes in the vicinity. Which conspires with (1), (2) and (3).
  5. It would introduce a single changeset that would be hard to bisect when things go wrong. And the things would go wrong, because of (1), (4) and partially by new opportunities presented by (2). For the C1 bug I mentioned above, I was able to quickly nail it through the bisection of my stack of atomic commits. That stack would not be available once we squash the commits/PRs before the integration.

So while on a surface it might look more enticing to purge everything at once, the amount of hassle we would endure is hard to justify. Doing this PR for port removal + multiple post-removal cleanups piecewise lets us reach the same final state without extra work, while doing so at leisurely pace and maintaining more convenient code history for future bug hunts.

Bottom-line: Let's not make our own lives harder unnecessarily. Atomic commits FTW.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2703337731

From duke at openjdk.org  Thu Mar  6 10:45:04 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 10:45:04 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
Message-ID: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>

Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.

This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.

Sponsored by: The FreeBSD Foundation
Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>

[1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

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

Commit messages:
 - 8351322: Parameterize link option for pthreads

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

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

From coleenp at openjdk.org  Thu Mar  6 12:38:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Mar 2025 12:38:53 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <vc_8BUQmGlQ49NItxWj8XCcs-NyifesE-ZqOYVGF8t8=.a345a768-d087-402a-bbb2-91430778573c@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com>
 <xKHhFYIxvCv8mkElhDeTpHcor35FkV9QdWLI0qY_SQc=.1b97dabc-fa7d-4940-bdfa-4e4915901c35@github.com>
 <vc_8BUQmGlQ49NItxWj8XCcs-NyifesE-ZqOYVGF8t8=.a345a768-d087-402a-bbb2-91430778573c@github.com>
Message-ID: <Zqze9MSfLGB7eW7e_hZ7TWNdEouVxJ_HiC3fgx8Mhcg=.2c9b3efe-7ff6-433b-b94e-86b1cf191398@github.com>

On Thu, 6 Mar 2025 09:48:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> So what, @iwanowww, you say is that this PR is indeed implementation of the JEP.
>>> And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP.
>>> Do I understand that correctly?
>> 
>> Yes.
>> 
>>> Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push.
>> 
>> It's definitely an option. But, most likely, there'll be some overlooked cases anyway (leading to additional followup RFEs). And the more convoluted the changes are the harder it is to validate their correctness, thus increasing the risks for product stability and delaying the integration. (I'm not sure how much time Aleksey and other contributors want to volunteer to this project.)  
>> 
>> Also, in case of AOT JEP the situation was quite the opposite: it started with a huge patch which was split into multiple mostly independent parts to streamline its review. For x86-32 code removal there's no such patch prepared yet and the complete scope of work is not clear yet.  
>> 
>> IMO the crucial part is to get the port officially retired. After that the rest can become a good source of starter tasks :-)
>
> Basically what @iwanowww said: this PR *is* the removal of x86_32 port.
> 
> After this PR integrates, it is not possible to build x86_32, because the core implementation of it is missing, and build system would refuse to even try building it. So this removes x86_32 port as the feature, atomically, matching the title and intent of the JEP. *Then*, follow-up subtasks RFE would clean up the parts of Hotspot that were added to support various x86_32-specific features, and are no longer needed anymore.
> 
> Honestly, I also believed the complete PR that cleans up every dusty corner at once would be more straight-forward. But then I tried it at https://github.com/openjdk/jdk/pull/22567. After investing a few full days on that draft PR, and listening to what people said about it, I firmly changed my mind, and can conclude that singular PR or series of stacked PRs are not a great way to go with this removal.
> 
> The massive drawbacks of complete/stacked PR are now obvious to me:
>   1. It is hard to review. The complete PR is huge, 210+ files affected. A lot of removals are logically connected across different files, and while they are simple in isolation, it is hard for a reviewer to separate several cleanups in large PRs. Stacked PRs would help some, but:
>   2. It accrues merge conflicts very fast. This happens even when mainline is somewhat idle without large feature integrations. I did complete PR near New Year holidays, and it was _already_ a headache. I expect this work to be even harder once we are closer to RDP1. It would be even more tedious with a chain of 10+ stacked PRs, as I got the preview of this when rebasing the stack of atomic commits in the complete draft PR several times.
>   3. It is hard to reach consensus on. Non-trivial changes require thorough review, and cobbling together multiple non-trivial changes require polynomially more coordination. I have seen this in Win32 port removal, so for a large PR like that I expect multiple, week-long review and amendment sessions. Which conspires with (1) and (2).
>   4. It is easy to introduce/overlook bugs. I already did this once in a complete PR when I accidentally removed the wrong part of C1 regalloc code, and it started ever so slightly misbehaving. And it was not obvious, because it was obscured by other changes in the vicinity, and it only failed one test in tier4. This conspires with (1), (2) and (3).
>   5. It would introduce a single changeset that would be hard to bisect when things go wrong. And the things wo...

Also @shipilev I'm jealous of all your code removal. :)  Well done getting agreement on this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2703725960

From coleenp at openjdk.org  Thu Mar  6 12:38:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Mar 2025 12:38:52 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <Dd1sLRnyToZ-3xsUkBaoFYGY2m6PkzgqFh08Q5nKPIQ=.9f079e30-f24c-4acc-a142-0ca5a1350b7e@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

I agree with @iwanowww's and @shipilev comments.  I would like to see this be the JEP implementation and the additional cleanups, particularly in the interpreter, handled one by one.  I don't see any advantage for one big integration push.  It'll be disruptive and for this, there is no scenario where this would be helpful to any future work.
When Aleksey sent out the original PR there were cleanups that needed explanation.  Finding the explanations in the big PR is a pain for scrolling.  And the reviewers for that part of the change were a different set than ones needed for this change.  Again for no benefit.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2664309410

From dholmes at openjdk.org  Thu Mar  6 12:41:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 12:41:03 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <tOBM8YCuhkVw2LYOGPMURzJzjl_yFdD-VWz_59PU5sY=.9c267874-ab4e-42df-8202-944600be1794@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

I am a bit confused here. libjsig is an application/end-user library. It sounds like something is statically linking libjsig and causing signal chaining to break. ???

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2703731729

From dholmes at openjdk.org  Thu Mar  6 12:49:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 12:49:02 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.

Needs build team approval before integrating.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2664340896

From duke at openjdk.org  Thu Mar  6 13:29:55 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 13:29:55 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
Message-ID: <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>

On Thu, 6 Mar 2025 12:46:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.

I noticed there were a few places that used `-pthread` by default. I left these alone in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2703853406

From duke at openjdk.org  Thu Mar  6 13:55:53 2025
From: duke at openjdk.org (Antonio Vieiro)
Date: Thu, 6 Mar 2025 13:55:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

make/test/JtregNativeHotspot.gmk line 886:

> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
> 885: else
> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)

Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
Could be me too, I need new reading glasses...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983396617

From erikj at openjdk.org  Thu Mar  6 14:06:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Mar 2025 14:06:55 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
In-Reply-To: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
Message-ID: <o7e9K46wOxsyOF938ySaRZrUtfNG3NScZS7pSAG0HmA=.92480c65-cc45-4e37-a8a1-5ea3bd1b7500@github.com>

On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.

Attempts at introducing any kind of code standard in OpenJDK has historically failed. It's a touchy subject to many. The bug description only really mentions `trim_trailing_whitespace` and since we are already enforcing this through jcheck, I don't see a problem or controversy adding that configuration here. As for the rest, I'm unsure.

The `indent_brace_style` isn't listed as an official property of EditorConfig (https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties). Is it actually picked up by any editor? Regardless, this isn't something that can just be snuck in.

What does `indent_style = tab` actually mean for makefiles? The tab character is used for defining recipe lines. Either an editor understands makefiles or it doesn't, I don't think this setting will be helpful. Also, most of our makefiles are *.gmk.

Defining indent_size for other source files is likely controversial, but if we were to go that route, then the set of `cpp,hpp,c,h` is not complete. Defining `indent_style = space` is likely ok for most kinds of sources, but again, I don't think we can just sneak this in like this.

My suggestion would be to only include the `trim_trailing_whitespace` line if you want to get this file in. After that you are free to start campaigning for more settings, but be prepared to work for it.

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

PR Review: https://git.openjdk.org/jdk/pull/23693#pullrequestreview-2664546757

From erikj at openjdk.org  Thu Mar  6 14:23:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Mar 2025 14:23:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

What is the intended way of using this? Do you run make with `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the specific way of linking to pthread?

make/autoconf/libraries.m4 line 142:

> 140:   # Threading library
> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"

If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.

Suggestion:

    BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

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

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2664582520
PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983435650

From ihse at openjdk.org  Thu Mar  6 15:51:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:51:52 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
Message-ID: <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>

On Thu, 6 Mar 2025 14:21:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?

This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.

> make/autoconf/libraries.m4 line 142:
> 
>> 140:   # Threading library
>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
> 
> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
> 
> Suggestion:
> 
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

Yes, this is incorrect. Remember that m4 are shell scripts so you need to use shell syntax here. (I know it is confusing).

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2704233217
PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983608153

From ihse at openjdk.org  Thu Mar  6 15:58:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:58:58 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
Message-ID: <oXeR7653mNNaWgQUd8T_KiQM8R987ZCjfuWAWNAoLLU=.a1980e25-ad0d-4da6-9bb2-92c13e790b28@github.com>

On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/test/JtregNativeHotspot.gmk line 886:
> 
>> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
>> 885: else
>> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)
> 
> Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
> Could be me too, I need new reading glasses...

You're absolutely right. 

@snake66 Making changes to makefiles is tricky, since a misspelled variable do not get any warning but is just silently ignored. 

For a change like this, that is a pure refactoring that is not supposed to change the output, I highly recommend using the `COMPARE_BUILD` system. Unfortunately, this is severely underdocumented. There is a short paragraph at https://openjdk.org/groups/build/doc/building.html under "Developing the Build System Itself", but in short, what I'd do is to create a diff files of these changes compared to a baseline (e.g. master, a specific build or commit), make sure you have the baseline checked out, and then run `make jdk-image test-image COMPARE_BUILD=PATCH=my_patch.diff`. This will build the targets twice, one without the patch and one with the patch, and then automatically run the `compare` script to analyze any differences. For this particular patch, there should be none. This would likely have caught this typo. (Given that the test-image is actually compared; I suddenly got a bit uncertain about that...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983618250

From ihse at openjdk.org  Thu Mar  6 15:58:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:58:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

make/Hsdis.gmk line 131:

> 129:     HSDIS_TOOLCHAIN_LIBS := $(MINGW_DLLCRT) -lmingw32 -lgcc -lgcc_eh -lmoldname \
> 130:         -lmingwex -lmsvcrt $(LIBPTHREAD) -ladvapi32 -lshell32 -luser32 -lkernel32
> 131:   else

The hsdis build is very weird and outside the normal integrated JDK build. I recommend you leave this instance alone. If you want to port hsdis to BSD you are likely to have to rewrite large parts of the compilation logic here anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983621784

From ihse at openjdk.org  Thu Mar  6 16:04:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 16:04:07 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <xsMMsbyZiYRdd28uG4tFr_2krbVDGwGbajN2UUJfP-4=.a8b5c3aa-178c-4e60-b9e7-5409421c9ea0@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

This is not the correct way to solve this. You should flag libjsig as `ONLY_EXPORTED` instead, which means that the library will not be included in a static build.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704270421

From ihse at openjdk.org  Thu Mar  6 16:13:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 16:13:59 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
In-Reply-To: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
Message-ID: <oRWmmBOJMtJ3rVAv-dOSleqToqSwlRsAs0z58qHHQis=.2f512ac3-3cbd-4f3d-b0d7-e802deb8a6f3@github.com>

On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.

I think a .editorconfig file is a good idea. There is an old feature request about this... _checking_ ... actually, I see you've found and reused that JBS bug. :-)

However, as Erik says, you need to be super careful not to try to enforce something that is not already enforced. I do support you in extending the scope of what rules we enforce, but as Erik says, prepare for an uphill battle.

I suggest you follow slavishly what the `.jcheck/conf` file prescribes:


[checks "whitespace"]
files=.*.cpp|.*.hpp|.*.c|.*.h|.*.java|.*.cc|.*.hh|.*.m|.*.mm|.*.S|.*.md|.*.properties|.*.gmk|.*.m4|.*.ac|Makefile
ignore-tabs=.*.gmk|Makefile


The "whitespace" check enforces, afaik, two things:
1) That there are no trailing whitespaces on a line
2) That all leading whitespaces are space (i.e., that tabs are forbidden).

The latter rule is removed by the `ignore-tabs` rule, since Makefile ascribes semantic differences to leading space and tabs (yeah, I know, it's braindead) and we need to allow both.

Note that no other file than what is matched by the regexp above are checked for whitespace. As a consequence, trailing whitespaces are galore in text files, xml files, you name it. So a rule that such whitespaces should be stripped would be highly disruptive, at least until these files are fixed and an enforcement rule is added to the jcheck file.

I don't know enough of the .editorconfig format to know if it is possible to express these rules exact, but if not, you better aim for a subset, rather than a superset.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2704297782

From ihse at openjdk.org  Thu Mar  6 16:21:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 16:21:54 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <cvZUOyaUr9G-miDbePX6Tmsum4Y5KMNjpTLKaL1W0Rc=.2096adec-dde0-4936-b18e-2090385b4349@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

make/autoconf/platform.m4 line 669:

> 667:   AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
> 668:       [Suppress the error when configuring for a deprecated port @<:@no@:>@])])
> 669:   # There are no deprecated ports. This option is left to be consistent with future deprecations.

Please remove. Old code is always present in git history if you want to reuse it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1983670151

From shade at openjdk.org  Thu Mar  6 16:40:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Mar 2025 16:40:58 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <cvZUOyaUr9G-miDbePX6Tmsum4Y5KMNjpTLKaL1W0Rc=.2096adec-dde0-4936-b18e-2090385b4349@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <cvZUOyaUr9G-miDbePX6Tmsum4Y5KMNjpTLKaL1W0Rc=.2096adec-dde0-4936-b18e-2090385b4349@github.com>
Message-ID: <HcpND1YQVUVwQSHAkJtm0v0zNwDZ7nRhLXW6Z3r0hQk=.b360c659-4103-4280-80dc-b11d2f81f7bb@github.com>

On Thu, 6 Mar 2025 16:18:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>> 
>> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
>> 
>> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
>> 
>> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
>
> make/autoconf/platform.m4 line 669:
> 
>> 667:   AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
>> 668:       [Suppress the error when configuring for a deprecated port @<:@no@:>@])])
>> 669:   # There are no deprecated ports. This option is left to be consistent with future deprecations.
> 
> Please remove. Old code is always present in git history if you want to reuse it.

I don't mind removing it, my concern would be to _remember_ this option was there! I guess it is okay to re-re-invent it later, possibly under a different name, when the next port gets deprecated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1983704213

From jiangli at openjdk.org  Thu Mar  6 16:59:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 16:59:56 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <7xslrGte187xJy22qg_3aY5Cwx-dwEumw5hGaYXhSzk=.95d0c93a-d812-48de-a276-a1939ac2f407@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <7xslrGte187xJy22qg_3aY5Cwx-dwEumw5hGaYXhSzk=.95d0c93a-d812-48de-a276-a1939ac2f407@github.com>
Message-ID: <DViYBMy1qVUSMhbqIgmtvE6z6GGf-rsHixHcj9xT9TI=.d5c51118-80d1-4bfe-91c1-8dd00c907050@github.com>

On Thu, 6 Mar 2025 05:55:48 GMT, Man Cao <manc at openjdk.org> wrote:

> libjsig is not supposed to be enabled by default. Per [Java 23 doc](https://docs.oracle.com/en/java/javase/23/troubleshoot/handle-signals-and-exceptions.html#GUID-CB49A2A7-2A9F-4C18-948F-6D4A96FF688D), it is user's choice whether to use libjsig.so. If they use it, they should either link the application with linker flag `-ljsig`, or use LD_PRELOAD.

For static JDK usages, the documentation would need to be updated when things are mature. There are cases where dynamic linking is not preferred and static linking should be used, and those are common in real world usages. We want to provide `libjsig.a` as part of the static bundle, users can link the launcher executable with `libjsig.a` for hermetic image if application wants to use `libjsig`. 

I think in general, using `libjsig.so` shared library is not an attractive solution on static & hermetic Java image, if application uses `libjsig`. In order to use `libjsig.so` for a hermetic Java image, there would be a separate regular JDK with the shared libraries installed into the target machine. Then it loses part of the benefits of using hermetic Java image.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704412958

From duke at openjdk.org  Thu Mar  6 17:21:01 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:21:01 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
Message-ID: <1xDhCbB5y6lKeTsljSaXQIctUdhLeZYMZc3ttv3CCAY=.e32e38b6-8431-4fa9-9b49-8fb305a744aa@github.com>

On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/test/JtregNativeHotspot.gmk line 886:
> 
>> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
>> 885: else
>> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)
> 
> Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
> Could be me too, I need new reading glasses...

@vieiro Thanks! That's well spotted, I'll fix!

@magicus Thanks for this info! I'll give it a try without fixing the typo first, to see if it would catch it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983764371

From duke at openjdk.org  Thu Mar  6 17:31:53 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:31:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>
Message-ID: <vLspqp3iNAf1V1PXvKB4844a1K71STekYMCWeTLLqv8=.ed29364e-71fa-4ca6-83a3-48435263cd3d@github.com>

On Thu, 6 Mar 2025 15:56:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/Hsdis.gmk line 131:
> 
>> 129:     HSDIS_TOOLCHAIN_LIBS := $(MINGW_DLLCRT) -lmingw32 -lgcc -lgcc_eh -lmoldname \
>> 130:         -lmingwex -lmsvcrt $(LIBPTHREAD) -ladvapi32 -lshell32 -luser32 -lkernel32
>> 131:   else
> 
> The hsdis build is very weird and outside the normal integrated JDK build. I recommend you leave this instance alone. If you want to port hsdis to BSD you are likely to have to rewrite large parts of the compilation logic here anyway.

Ack, I'll drop that one from the patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983780437

From duke at openjdk.org  Thu Mar  6 17:31:54 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:31:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
Message-ID: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>

On Thu, 6 Mar 2025 14:15:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/autoconf/libraries.m4 line 142:
> 
>> 140:   # Threading library
>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
> 
> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
> 
> Suggestion:
> 
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

@erikj79 There will be a later patch to libraries.m4 that sets the variable based on the target platform, and then populates the `LIBPTHREAD` variable in spec.gmk. (https://github.com/openjdk/jdk/pull/23930/files#diff-56172cd2ec5804a5f764a6d0d5970da6144b024a06e008571f9822b2dc83cc36R147) That means the parenthesis should stay, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983779126

From jiangli at openjdk.org  Thu Mar  6 17:47:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 17:47:02 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <tOBM8YCuhkVw2LYOGPMURzJzjl_yFdD-VWz_59PU5sY=.9c267874-ab4e-42df-8202-944600be1794@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <tOBM8YCuhkVw2LYOGPMURzJzjl_yFdD-VWz_59PU5sY=.9c267874-ab4e-42df-8202-944600be1794@github.com>
Message-ID: <olHib3T2rGvzx0Umxn_KJwFFEhu-WWik301Rg-IAUmc=.0bcd6819-b795-4579-becb-75239daf054f@github.com>

On Thu, 6 Mar 2025 12:37:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I am a bit confused here. libjsig is an application/end-user library. 

libjsig is provided by JDK.

> It sounds like something is statically linking libjsig and causing signal chaining to break. ???

AFAICT, signal chaining works when libjsig is statically linked (I stepped through the code in `gdb` and checked).

TestPosixSig.java failure is a test problem. The test looks for the print output from `os::run_periodic_checks`. The periodic signal checker is disabled, when libjsig is used. See https://github.com/openjdk/jdk/blob/08929134b3533362133139c4e964b1b28de6ebfb/src/hotspot/os/posix/signals_posix.cpp#L1359:


  // We don't activate signal checker if libjsig is in place, we trust ourselves
  // and if UserSignalHandler is installed all bets are off.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704532379

From jiangli at openjdk.org  Thu Mar  6 17:47:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 17:47:02 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <xsMMsbyZiYRdd28uG4tFr_2krbVDGwGbajN2UUJfP-4=.a8b5c3aa-178c-4e60-b9e7-5409421c9ea0@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <xsMMsbyZiYRdd28uG4tFr_2krbVDGwGbajN2UUJfP-4=.a8b5c3aa-178c-4e60-b9e7-5409421c9ea0@github.com>
Message-ID: <cBpjD8iwhgtDgqSiTXT_Uf-hlTTM2_kzq71gPCh9eo8=.a832cc84-650a-4f6d-8de9-451de99ada07@github.com>

On Thu, 6 Mar 2025 16:01:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is not the correct way to solve this. You should flag libjsig as `ONLY_EXPORTED` instead, which means that the library will not be included in a static build.

I think we do want to include `libjsig.a` as part of the JDK static libs. When users build application hermetic image, they can choose to whether statically link with or without `libjsig.a`. See my other comments for more details, https://github.com/openjdk/jdk/pull/23924#issuecomment-2704412958.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704537513

From ihse at openjdk.org  Thu Mar  6 18:18:06 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 18:18:06 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <odBfyDrIIo1TUH2xkYRM0GNZXICxrS3mftuebHEZ8b4=.e29b6ced-7be9-4577-8d52-d8e7a0e1dc2b@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

But if we do not link it with the launcher, it will not get tested. I don't think it is a good idea to provide a binary that have not even had a shred of testing. I'm rather leaning towards saying that signal chaining is not possible for a static JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704602444

From ihse at openjdk.org  Thu Mar  6 18:24:05 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 18:24:05 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>
Message-ID: <8oD1j-gxmzv2_5BOV5GohhkiKcuTDqxAC-3mnF8i-3o=.f2d870af-a508-4b53-95ac-d886fdc21b09@github.com>

On Thu, 6 Mar 2025 17:28:10 GMT, snake66 <duke at openjdk.org> wrote:

>> make/autoconf/libraries.m4 line 142:
>> 
>>> 140:   # Threading library
>>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
>> 
>> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
>> 
>> Suggestion:
>> 
>>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"
>
> @erikj79 There will be a later patch to libraries.m4 that sets the variable based on the target platform, and then populates the `LIBPTHREAD` variable in spec.gmk. (https://github.com/openjdk/jdk/pull/23930/files#diff-56172cd2ec5804a5f764a6d0d5970da6144b024a06e008571f9822b2dc83cc36R147) That means the parenthesis should stay, right?

I'm not sure what you mean now. The link is to this very patch, which does what you describe -- sets LIBPTHREAD according to OS and stores it in spec.gmk.

And no, the paranthesis should not stay. If you keep them, the variable will be re-evaluated in make every time BASIC_JVM_LIBS is evaluated. That is not needed; by dropping the parenthesis the actual value to be used will be inserted as a string constant. Which is what we want, since we know the value at configure time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983853576

From ihse at openjdk.org  Thu Mar  6 18:25:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 18:25:54 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <HcpND1YQVUVwQSHAkJtm0v0zNwDZ7nRhLXW6Z3r0hQk=.b360c659-4103-4280-80dc-b11d2f81f7bb@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <cvZUOyaUr9G-miDbePX6Tmsum4Y5KMNjpTLKaL1W0Rc=.2096adec-dde0-4936-b18e-2090385b4349@github.com>
 <HcpND1YQVUVwQSHAkJtm0v0zNwDZ7nRhLXW6Z3r0hQk=.b360c659-4103-4280-80dc-b11d2f81f7bb@github.com>
Message-ID: <ZE8xCvaV43R1NwFC043lKBgz4eOE-2ayAfYPWULRIFY=.aa2c7cc9-dc4e-47a2-973e-a330e0dddee8@github.com>

On Thu, 6 Mar 2025 16:38:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> make/autoconf/platform.m4 line 669:
>> 
>>> 667:   AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
>>> 668:       [Suppress the error when configuring for a deprecated port @<:@no@:>@])])
>>> 669:   # There are no deprecated ports. This option is left to be consistent with future deprecations.
>> 
>> Please remove. Old code is always present in git history if you want to reuse it.
>
> I don't mind removing it, my concern would be to _remember_ this option was there! I guess it is okay to re-re-invent it later, possibly under a different name, when the next port gets deprecated.

It's no that important, no. I'm not sure if previous deprecated ports were handles exactly like this. 

And you can always do like `git log | grep -i "remove .* port"` to find the change it was removed in, and look what it did...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1983855800

From jiangli at openjdk.org  Thu Mar  6 18:32:51 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 18:32:51 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <odBfyDrIIo1TUH2xkYRM0GNZXICxrS3mftuebHEZ8b4=.e29b6ced-7be9-4577-8d52-d8e7a0e1dc2b@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <odBfyDrIIo1TUH2xkYRM0GNZXICxrS3mftuebHEZ8b4=.e29b6ced-7be9-4577-8d52-d8e7a0e1dc2b@github.com>
Message-ID: <Fn4Qdcs5cCTGCnwgKiMExfdI34DNeHLCuh8hp5ToSY8=.2eb7a1e1-e262-45f5-b8d0-ba26067413ba@github.com>

On Thu, 6 Mar 2025 18:15:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> But if we do not link it with the launcher, it will not get tested. I don't think it is a good idea to provide a binary that have not even had a shred of testing. I'm rather leaning towards saying that signal chaining is not possible for a static JDK.

Signal chaining works on static. So I don't think we should say it's not possible. :-)

I had some thoughts on testing earlier. For testing we want to create a test that builds a hermetic image (when supported in mainline) that statically links with the libjsig.a, to exercise the signal chaining in that combination.  We should create a bug for that so we don't forget.

The main point is that we don't want to test with signal chaining enabled by default on static JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704637419

From ihse at openjdk.org  Thu Mar  6 18:53:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 18:53:02 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <sSoJ-OWRvapCfaq9rGvJ3UgA85G6UN6psApugzDV6JE=.f76e3338-f525-48b5-9d5c-9bff1cba2f8d@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

I meant more like "not supported". You are correct that it is technically possible.

How useful is signal chaining even these days? 

While we could do something like this, I see more trouble ahead. How should we do when we put the static libs in a jmod? Should all static libraries have an "optional/required" flag attached to them? How do the user select if libjsig should be included or not?

I would argue that for the time being, it is better to set libjsig as `ONLY_EXPORTED`, and if/when we get back to revisit this, we can start compiling it always, and then we will also have a story on how to test it, how to handle it in jmods, etc, including perhaps a better idea on how important it is to have signal chaining for static builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704678008

From henryjen at openjdk.org  Thu Mar  6 19:01:10 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 6 Mar 2025 19:01:10 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <S1gZqQYy0pp5-YnYjKRD1h3MdWSZ-yLP9G_Ix3q9sRY=.756f355d-a52e-4659-8076-ad67bf2462f9@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

IIUC, signal chaining is a link time question for native executable using hotspot(launchers), the `java` launcher in regular JDK build is disabled by default unless user preload the libjsig.

So, for the future jmod to support static linking, it could include libjsig.a or leave it out and have user to explicit download and link their native application.

As for the `java` launcher in hermetic java, we need to decide whether we want to support signal chaining by default, and update the test accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704694954

From jiangli at openjdk.org  Thu Mar  6 19:26:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 19:26:58 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <sSoJ-OWRvapCfaq9rGvJ3UgA85G6UN6psApugzDV6JE=.f76e3338-f525-48b5-9d5c-9bff1cba2f8d@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <sSoJ-OWRvapCfaq9rGvJ3UgA85G6UN6psApugzDV6JE=.f76e3338-f525-48b5-9d5c-9bff1cba2f8d@github.com>
Message-ID: <QXzAD8_S8i8inXeDN8ZxKHgzGocZWhN3lfyPQtO0Ir4=.b518d967-c96b-4842-99d4-ed9a32ffea40@github.com>

On Thu, 6 Mar 2025 18:49:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I meant more like "not supported". You are correct that it is technically possible.
> 
> How useful is signal chaining even these days?
> 
> While we could do something like this, I see more trouble ahead. How should we do when we put the static libs in a jmod? Should all static libraries have an "optional/required" flag attached to them? How do the user select if libjsig should be included or not?
> 
> I would argue that for the time being, it is better to set libjsig as `ONLY_EXPORTED`, and if/when we get back to revisit this, we can start compiling it always, and then we will also have a story on how to test it, how to handle it in jmods, etc, including perhaps a better idea on how important it is to have signal chaining for static builds.

I think I could be convinced, but it probably not a decision could be made by just us. :-) I think it would require broader discussion and decision making on if the JDK signal chaining provided by libjsig should be supported on static JDK. That decision probably should be made as part of a JEP process when we move to that step.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704744091

From jiangli at openjdk.org  Thu Mar  6 19:26:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 19:26:58 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <S1gZqQYy0pp5-YnYjKRD1h3MdWSZ-yLP9G_Ix3q9sRY=.756f355d-a52e-4659-8076-ad67bf2462f9@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <S1gZqQYy0pp5-YnYjKRD1h3MdWSZ-yLP9G_Ix3q9sRY=.756f355d-a52e-4659-8076-ad67bf2462f9@github.com>
Message-ID: <KgcH9GQPtuKmVdKzY_bzz4A0F-wc5Xi9-Dnnu9VWJkw=.e5114063-1534-40da-9d2b-241ad2c70cd2@github.com>

On Thu, 6 Mar 2025 18:57:48 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> IIUC, signal chaining is a link time question for native executable using hotspot(launchers), the `java` launcher in regular JDK build is disabled by default unless user preload the libjsig.
> 
> So, for the future jmod to support static linking, it could include libjsig.a or leave it out and have user to explicit download and link their native application.
> 
> As for the `java` launcher in hermetic java, we need to decide whether we want to support signal chaining by default, and update the test accordingly.

Right. And, I think we should not enable that by default to keep the same behavior as on regular JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704747810

From ihse at openjdk.org  Thu Mar  6 20:23:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 20:23:53 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <p6S-uNlOnLC9lqyJ4LhelYM0tjAu9wc3Xan2ULf9vPE=.05406ef1-8313-4cf5-ac46-3281edadbb82@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

It seems we agree that we need, at some point, to have a high-level discussion on if libjsig should be supported on static builds, and if so, how it should be implemented. We also agree that having signal chaining enabled by default on our static JDK builds are incorrect.

However, I suggest we chose a simple path, were we utilize the framework for not building a static library that we do not use (this is already done for several libraries that are not included in the static JDK image), while you suggest we keep compiling it, even if we do not include it and test it. 

I don't get the point of this. If we don't include it, and don't test it, then surely it would be better to not even build it now?

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2704857060

From jiangli at openjdk.org  Thu Mar  6 21:47:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 21:47:57 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <p6S-uNlOnLC9lqyJ4LhelYM0tjAu9wc3Xan2ULf9vPE=.05406ef1-8313-4cf5-ac46-3281edadbb82@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <p6S-uNlOnLC9lqyJ4LhelYM0tjAu9wc3Xan2ULf9vPE=.05406ef1-8313-4cf5-ac46-3281edadbb82@github.com>
Message-ID: <GC06yaeFbz0HY6-P4IH2qMT99jlUBAkvCoiV8lOzbx4=.0d4f63f6-c64c-4734-8aa6-9f8e041021f3@github.com>

On Thu, 6 Mar 2025 20:20:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It seems we agree that we need, at some point, to have a high-level discussion on if libjsig should be supported on static builds, and if so, how it should be implemented. We also agree that having signal chaining enabled by default on our static JDK builds are incorrect.

Thumbs up.

> 
> However, I suggest we chose a simple path, were we utilize the framework for not building a static library that we do not use (this is already done for several libraries that are not included in the static JDK image), while you suggest we keep compiling it, even if we do not include it and test it.
> 
> I don't get the point of this. If we don't include it, and don't test it, then surely it would be better to not even build it now?

We have no current usages of libjsig in our current hermetic Java testing and prototype development work. So I don't have related concerns if don't produce a `libjsig.a` in the `static-libs` for the short term. Let's check with @dougxc and others from GraalVM side to make sure that they are okay with removing `libjsig.a` from the static libs bundle, before making any changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705012476

From jiangli at openjdk.org  Thu Mar  6 22:26:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 22:26:56 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <N8-MA4uLOU1L1dhdgAzd72sUQDBhIPIbC8Nc2HNb1Qw=.92900c9b-5f88-4526-825a-df71ce606aa1@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

I filed https://bugs.openjdk.org/browse/JDK-8351367 for deciding the overall libjsig signal chaining support on static JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705076539

From dholmes at openjdk.org  Fri Mar  7 00:20:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 00:20:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
Message-ID: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>

On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> What is the intended way of using this? Do you run make with `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the specific way of linking to pthread?
>
>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
> 
> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.

@magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2705227213

From dholmes at openjdk.org  Fri Mar  7 07:20:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 07:20:58 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <vc_8BUQmGlQ49NItxWj8XCcs-NyifesE-ZqOYVGF8t8=.a345a768-d087-402a-bbb2-91430778573c@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com>
 <xKHhFYIxvCv8mkElhDeTpHcor35FkV9QdWLI0qY_SQc=.1b97dabc-fa7d-4940-bdfa-4e4915901c35@github.com>
 <vc_8BUQmGlQ49NItxWj8XCcs-NyifesE-ZqOYVGF8t8=.a345a768-d087-402a-bbb2-91430778573c@github.com>
Message-ID: <tiENJY_-jSu6BwPzkT8JiK551kqwT8wiK3gGcl3VFhg=.6b7fc9d0-7a11-40ae-ab4a-1f555157c653@github.com>

On Thu, 6 Mar 2025 09:48:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After this PR integrates, it is not possible to build x86_32

You could add a couple of lines to the build code and it would not be possible to build 32-bit, so that is a necessary but not sufficient condition to claim to implement the JEP IMO.

I'm not looking for one big PR, I'm looking for multiple PR's as proposed but which all fall under the JEP umbrella. Until the JEP is targeted then nothing can be integrated anyway. This is what, I thought, dependent PR's were designed for.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2705707504

From dholmes at openjdk.org  Fri Mar  7 07:23:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 07:23:54 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <ZE8xCvaV43R1NwFC043lKBgz4eOE-2ayAfYPWULRIFY=.aa2c7cc9-dc4e-47a2-973e-a330e0dddee8@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <cvZUOyaUr9G-miDbePX6Tmsum4Y5KMNjpTLKaL1W0Rc=.2096adec-dde0-4936-b18e-2090385b4349@github.com>
 <HcpND1YQVUVwQSHAkJtm0v0zNwDZ7nRhLXW6Z3r0hQk=.b360c659-4103-4280-80dc-b11d2f81f7bb@github.com>
 <ZE8xCvaV43R1NwFC043lKBgz4eOE-2ayAfYPWULRIFY=.aa2c7cc9-dc4e-47a2-973e-a330e0dddee8@github.com>
Message-ID: <cTRgAAA0B5QD80WXj4zUi1BqGX7aPtkvRVXMN_BdQ-Y=.b377ddb4-cd40-4480-9237-c68f0cc56b39@github.com>

On Thu, 6 Mar 2025 18:23:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I don't mind removing it, my concern would be to _remember_ this option was there! I guess it is okay to re-re-invent it later, possibly under a different name, when the next port gets deprecated.
>
> It's no that important, no. I'm not sure if previous deprecated ports were handles exactly like this. 
> 
> And you can always do like `git log | grep -i "remove .* port"` to find the change it was removed in, and look what it did...

I think leaving a comment describing how to deprecate a port is useful. To look it up in history you have to realise there is something to look up.

"They who are not reminded of the past will invent a new way to do it in the future."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1984572816

From dholmes at openjdk.org  Fri Mar  7 07:43:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 07:43:53 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <olHib3T2rGvzx0Umxn_KJwFFEhu-WWik301Rg-IAUmc=.0bcd6819-b795-4579-becb-75239daf054f@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <tOBM8YCuhkVw2LYOGPMURzJzjl_yFdD-VWz_59PU5sY=.9c267874-ab4e-42df-8202-944600be1794@github.com>
 <olHib3T2rGvzx0Umxn_KJwFFEhu-WWik301Rg-IAUmc=.0bcd6819-b795-4579-becb-75239daf054f@github.com>
Message-ID: <K49N0AawBbmqvKdOTCKXnzRwX-SR4xlcCE4gakuq6DQ=.ed5d34b8-855c-415c-90dd-76077aa60d40@github.com>

On Thu, 6 Mar 2025 17:42:04 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> libjsig is provided by JDK.

Yes for an application to chose to use so that its own signal usage can be better integrated with that of the JDK. Statically linking libjsig with a JDK makes no sense to me at all.

> TestPosixSig.java failure is a test problem. The test looks for the print output from os::run_periodic_checks. The periodic signal checker is disabled, when libjsig is used.

So the test fails if you have statically linked libjsig into a JDK image. My response is "don't do that".

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705746190

From dholmes at openjdk.org  Fri Mar  7 07:47:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 07:47:56 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <QXzAD8_S8i8inXeDN8ZxKHgzGocZWhN3lfyPQtO0Ir4=.b518d967-c96b-4842-99d4-ed9a32ffea40@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <sSoJ-OWRvapCfaq9rGvJ3UgA85G6UN6psApugzDV6JE=.f76e3338-f525-48b5-9d5c-9bff1cba2f8d@github.com>
 <QXzAD8_S8i8inXeDN8ZxKHgzGocZWhN3lfyPQtO0Ir4=.b518d967-c96b-4842-99d4-ed9a32ffea40@github.com>
Message-ID: <B0vuC4sdPrth7FosusOcy4jmmH116m_tkETCWf1XPOY=.d6714c98-7502-4d0b-9662-b3b39ebf1312@github.com>

On Thu, 6 Mar 2025 19:22:23 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> How useful is signal chaining even these days?

@magicus as useful as it has ever been if your application uses signals that overlap with JVM usage.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705751155

From dnsimon at openjdk.org  Fri Mar  7 09:24:59 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 7 Mar 2025 09:24:59 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <GC06yaeFbz0HY6-P4IH2qMT99jlUBAkvCoiV8lOzbx4=.0d4f63f6-c64c-4734-8aa6-9f8e041021f3@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <p6S-uNlOnLC9lqyJ4LhelYM0tjAu9wc3Xan2ULf9vPE=.05406ef1-8313-4cf5-ac46-3281edadbb82@github.com>
 <GC06yaeFbz0HY6-P4IH2qMT99jlUBAkvCoiV8lOzbx4=.0d4f63f6-c64c-4734-8aa6-9f8e041021f3@github.com>
Message-ID: <qrKql-eXWcuqGXg57SMHLgW4c6fu62bWr4-GCig9VPU=.aae9bd61-0ee6-4950-894b-7e8aeccf67ac@github.com>

On Thu, 6 Mar 2025 21:45:29 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Let's check with @dougxc and others from GraalVM side

@wirthi or someone from the Native Image team will comment on this. Thanks for the heads up.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705943175

From jkern at openjdk.org  Fri Mar  7 09:33:35 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 7 Mar 2025 09:33:35 GMT
Subject: RFR: 8351399: AIX: Better solution than JDK8348663
Message-ID: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>

With
[JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes the burned-in library search paths of the generated executables
an ugly workaround was introduced to get rid of the unwanted list of search libraries the clang compiler automatically burns into the executable files.
Now we have a better solution, using just a different linker flag.
Instead of using the linker option -bnolibpath, which forces the LIBPATH env variable to be burned in, we now use the -blibpath:/usr/lib:lib option, which explicitly tells what to burn in.
I will revert the last change of [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) and introduce this new change.

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

Commit messages:
 - JDK-8351399

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

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

From jkern at openjdk.org  Fri Mar  7 09:36:54 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 7 Mar 2025 09:36:54 GMT
Subject: RFR: 8351399: AIX: Better solution than JDK8348663
In-Reply-To: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
References: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
Message-ID: <xvL9iBq4anDF1xiQxqDFOHLmyyWGPuSLO2AnomEWYjE=.00978b5a-e448-4bc4-997d-59849c344fa5@github.com>

On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search libraries the clang compiler automatically burns into the executable files.
> Now we have a better solution, using just a different linker flag.
> Instead of using the linker option -bnolibpath, which forces the LIBPATH env variable to be burned in, we now use the -blibpath:/usr/lib:lib option, which explicitly tells what to burn in.
> I will revert the last change of [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) and introduce this new change.

@magicus: To make you happy I have found a simple solution to get rid of the ugly shell script wrapper to clean the burned library path. Please take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/23942#issuecomment-2705966667

From stuefe at openjdk.org  Fri Mar  7 09:41:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Mar 2025 09:41:53 GMT
Subject: RFR: 8351399: AIX: Better solution than JDK8348663
In-Reply-To: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
References: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
Message-ID: <SPWhD8NaGrqN0btgzZmgBea0TQXZB5A6uDePFkrm9yI=.f2b3c98e-45db-4ce7-828b-017f81b508fa@github.com>

On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search libraries the clang compiler automatically burns into the executable files.
> Now we have a better solution, using just a different linker flag.
> Instead of using the linker option -bnolibpath, which forces the LIBPATH env variable to be burned in, we now use the -blibpath:/usr/lib:lib option, which explicitly tells what to burn in.
> I will revert the last change of [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) and introduce this new change.

Very good.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23942#pullrequestreview-2666734903

From stuefe at openjdk.org  Fri Mar  7 09:49:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Mar 2025 09:49:57 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <vd2ekkHxxIlEzFqjbPvaLhF2en5GC8AxkhgG2Opga7A=.67342556-18ff-4c2b-b493-ccd9844278dd@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

To me this feels like a valid solution. Barring objections by others, I am fine with it.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23924#pullrequestreview-2666754546

From stuefe at openjdk.org  Fri Mar  7 09:49:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Mar 2025 09:49:58 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <QXzAD8_S8i8inXeDN8ZxKHgzGocZWhN3lfyPQtO0Ir4=.b518d967-c96b-4842-99d4-ed9a32ffea40@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <sSoJ-OWRvapCfaq9rGvJ3UgA85G6UN6psApugzDV6JE=.f76e3338-f525-48b5-9d5c-9bff1cba2f8d@github.com>
 <QXzAD8_S8i8inXeDN8ZxKHgzGocZWhN3lfyPQtO0Ir4=.b518d967-c96b-4842-99d4-ed9a32ffea40@github.com>
Message-ID: <uJEIBjslJz5K6nXDuqggr68mXEAFo8T3LcPJsZn_84M=.168de488-d1f3-4c12-8d1c-69a91b7f3d6b@github.com>

On Thu, 6 Mar 2025 19:22:23 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> I meant more like "not supported". You are correct that it is technically possible.
> 
> How useful is signal chaining even these days?
> 

It is a niche solution to a complex problem (using signals in third-party native libraries which do their signal setup after hotspot signal setup has happened, preventing the library from messing up the hotspot signal mechanism). It is certainly used and needs to continue existing.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705990399

From mdoerr at openjdk.org  Fri Mar  7 10:51:56 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 7 Mar 2025 10:51:56 GMT
Subject: RFR: 8351399: AIX: Better solution than JDK8348663
In-Reply-To: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
References: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
Message-ID: <Q7eNY-kyCFmYFvQovyyVbxLqQ-pIwDfvDvYOfzXJRIE=.9f7e27c1-5d62-4874-a1c2-4e3571604d01@github.com>

On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search libraries the clang compiler automatically burns into the executable files.
> Now we have a better solution, using just a different linker flag.
> Instead of using the linker option -bnolibpath, which forces the LIBPATH env variable to be burned in, we now use the -blibpath:/usr/lib:lib option, which explicitly tells what to burn in.
> I will revert the last change of [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) and introduce this new change.

This solution looks much better!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23942#pullrequestreview-2666913626

From ihse at openjdk.org  Fri Mar  7 11:25:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 11:25:52 GMT
Subject: RFR: 8351399: AIX: Better solution than JDK8348663
In-Reply-To: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
References: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
Message-ID: <ZWR_RYmCU2T8j3Gs1c1eY3hnG68X8aQay9uoAQYsQYk=.c82ea35f-21d0-4826-8e2d-bae926440d84@github.com>

On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search libraries the clang compiler automatically burns into the executable files.
> Now we have a better solution, using just a different linker flag.
> Instead of using the linker option -bnolibpath, which forces the LIBPATH env variable to be burned in, we now use the -blibpath:/usr/lib:lib option, which explicitly tells what to burn in.
> I will revert the last change of [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) and introduce this new change.

Indeed you make me very happy! ?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23942#pullrequestreview-2666983747

From ihse at openjdk.org  Fri Mar  7 11:29:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 11:29:58 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <HlyLh3rZwyf-V0wCwNpzfPnFK7G7F1N3SDD_HY1Fx-Q=.809f5680-f8ae-46b3-b368-dde14d0bd3f6@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

I agree with David here. Yes, implementing this multiple PRs is the correct approach (I think we all agree on this). However, it seems strange to mark just this single PR as implementing the JEP. Instead, that honor should fall on an umbrella JBS issue, which is dependent on this PR, but also the other planned updates. Before these are done, we can't really say that the JEP is implemented. In practical terms it does not mean much, but the bookkeeping seems better aligned with reality in that way.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2706212136

From ihse at openjdk.org  Fri Mar  7 11:34:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 11:34:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: <ZF1daFkBTlQ8lrEMRD3alDurQiOp02Q-5YYJ822f0GE=.24d747ef-9efe-497f-b792-58850aff5467@github.com>

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

@dholmes-ora Good question. I don't know the answer. I know we used `-pthread` exclusively on Solaris, and that we've used `-lpthread` on Linux (but apparently not in all cases?). I guess this difference would not have been introduced when the Linux port was created from the Solaris port unless it made sense. So maybe at that time, GCC did not support `-pthread`. Otoh, that might have changed by now.

Regardless, I would still like to see this change. We have generalized almost all system libraries to variable (like `$LIBM`, `$LIBDL` etc), and this is the last remaining (I think).

We can then check if we can turn `-lpthread` into `-pthread` on Linux as a follow up.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2706220845

From ihse at openjdk.org  Fri Mar  7 12:03:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 12:03:13 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <UZ7o3EbaKrcToWfCY395VnTBwtGPRqTeLVcOqElj1Es=.8ebac174-c9de-4289-a44b-7a05febe252b@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
 <UZ7o3EbaKrcToWfCY395VnTBwtGPRqTeLVcOqElj1Es=.8ebac174-c9de-4289-a44b-7a05febe252b@github.com>
Message-ID: <uTD53V9aGqZELThLytg9BqOOGuuAUnDkoTh5o20AYPc=.621c48f6-78b9-49b4-bbf4-0bef04dc625b@github.com>

On Sat, 11 Mar 2023 16:07:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AccessBridgeJavaEntryPoints.cpp
>
> Oops, didn't mean to do that. Oh well, will update this again later

@TheShermanTanker This seems like a good fix to make VSC++ behave according to standard. I think it should be resurrected.

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706274916

From galder at redhat.com  Fri Mar  7 13:29:47 2025
From: galder at redhat.com (Galder Zamarreno)
Date: Fri, 7 Mar 2025 14:29:47 +0100
Subject: Nix shell for building OpenJDK on macOS
Message-ID: <CAAcPREssgBjNxtDeeD0S_VGFRjRbX_6mFDUEHrLez7FEZYXTFg@mail.gmail.com>

Hi,

The dependencies required to build JDK vary depending on which JDK version
you are building. I've been building my own set of scripts that allows me
to easily manage this, to the extent that I can do it on the given base OS
I run. E.g. if I'm building a mainline I'd use X as boot JDK but if I'm
building a JDK 21 backport I'd use Y as boot JDK. These scripts are
cumbersome and they can't control all tooling dependencies, so their use is
limited.

In my spare time I've been experimenting with Nix, which offers a
declarative way for package management and system configuration. Its
package manager can be installed on either Linux or Mac and enables you to
start shell instances with a set of isolated dependencies.

I've been wanting to move from my cumbersome scripts to a setup that
allows me to build my local JDKs within a Nix isolated shell. However,
although Nix packages exist that build OpenJDK [1], these only support
Linux and I'm often developing on a mac. After some exploration, I've been
able to craft a Nix descriptor file that allows me to build JDK in an
isolated Nix shell on a mac. I wanted to share this in this mailing list in
case it is useful to other JDK developers.

The starting point is having a mac devkit. Since I'm not a Nix expert I
built it outside of Nix, e.g.

```
$ cd jdk/make/devkit
$ bash ./createMacosxDevkit.sh /Applications/Xcode.app
```

Then I added the devkit manually to the Nix store:

```
$ cd jdk/build/devkit
$ nix-store --add-fixed --recursive sha256 Xcode16.2-MacOSX15
/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15
```

Then I created a shell.nix file that declares the dependencies and sets
environment variables to build the JDK successfully. Something that is odd
is that if you depend on pkgs.jdk23 on mac, it doesn't throw an error
because [1] is not supported there, but it downloads Azul's Zulu JDK. I've
asked how this happens [2] but didn't get a satisfactory answer but this is
ok for now for a boot jdk. The DEVKIT env variable points to the devkit I
added to the nix store and MIGCC is set so that the JDK build uses the
clang from the package dependency.

```
{ pkgs ? import <nixpkgs> {} }:

let
  devkit = "/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15";
in
pkgs.mkShell {
  packages = [
    pkgs.autoconf
    pkgs.jdk23
    pkgs.clang

    devkit
  ];

  shellHook = ''
    echo "Setting DEVKIT_ROOT to path of the devkit in the Nix store."
    export DEVKIT_ROOT=${devkit}

    echo "Setting MIGCC to clang compiler cc binary."
    export MIGCC="${pkgs.clang}/bin/cc"
  '' ;
}
```

>From the directory where the shell.nix file is located you can start a Nix
shell that will start the isolated environment:

```
nix-shell
```

In that nix-shell you can now configure the JDK pointing the boot JDK and
the devkit:

```
[nix-shell: jdk] $ bash configure \
    --with-boot-jdk=$(dirname $(dirname $(readlink -f $(which java)))) \
    --with-devkit=$DEVKIT_ROOT
```

The configure output looks like this:

```
A new configuration has been successfully created in
/Users/galder/1/colata/nix-darwin/jdk/build/macosx-aarch64-server-release
using configure arguments
'--with-boot-jdk=/nix/store/wm5rma6x2527qmypzj7rwml8vf9vprgj-zulu-ca-jdk-23.0.0/zulu-23.jdk/Contents/Home
--with-devkit=/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15'.

Configuration summary:
* Name:           macosx-aarch64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'cds compiler1 compiler2 dtrace epsilongc g1gc
jfr jni-check jvmci jvmti management parallelgc serialgc services
shenandoahgc vm-structs zgc'
* OpenJDK target: OS: macosx, CPU architecture: aarch64, address length: 64
* Version string: 25-internal-adhoc.galder.jdk (25-internal)
* Source date:    315532800 (1980-01-01T00:00:00Z)

Tools summary:
* Boot JDK:       openjdk version "23" 2024-09-17 OpenJDK Runtime
Environment Zulu23.28+85-CA (build 23+37) OpenJDK 64-Bit Server VM
Zulu23.28+85-CA (build 23+37, mixed mode, sharing) (at
/nix/store/wm5rma6x2527qmypzj7rwml8vf9vprgj-zulu-ca-jdk-23.0.0/zulu-23.jdk/Contents/Home)
* Toolchain:      clang (clang/LLVM from Xcode 16.2)
* Devkit:         Xcode 16.2 (devkit)
(/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15)
* C Compiler:     Version 16.0.0 (at
/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang)
* C++ Compiler:   Version 16.0.0 (at
/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++)

Build performance summary:
* Build jobs:     14
* Memory limit:   49152 MB
```

Then you can just run make and verify the JDK version:

```
[nix-shell: jdk] $ make
...
Finished building target 'default (exploded-image)' in configuration
'macosx-aarch64-server-release'

[nix-shell: jdk] $ ./build/macosx-aarch64-server-release/jdk/bin/java
--version
openjdk 25-internal 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.galder.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.galder.jdk, mixed mode)
```

The above is sufficient for my own use case, but it can be enhanced further
to add capstone dependency...etc.

I don't know who is taking care of [1] but while working on this a member
in Nix macos discord asked me to create an issue in Nix packages so that
others can maybe take this further and enhance [1] so that it also supports
darwin-aarch64. So I created [3].

XCode is tricky to handle, but it would be great if eventually there would
be Nix packages for JDK devkits for macos. If those were available, it
would enable OpenJDK developers to build earlier JDK versions even of the
very latest macos environments, by depending on earlier XCode version based
JDK devkits. You could also pick whichever clang, capstone...etc version
that matches that...etc.

Thanks
Galder

[1]
https://github.com/NixOS/nixpkgs/blob/nixos-24.11/pkgs/development/compilers/openjdk/generic.nix
[2] https://github.com/NixOS/nixpkgs/issues/377908
[3] https://github.com/NixOS/nixpkgs/issues/387516
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250307/fddaa44b/attachment-0001.htm>

From ihse at openjdk.org  Fri Mar  7 13:40:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 13:40:00 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v3]
In-Reply-To: <X5_T2W7WfR0HHk1-56XGtop1jOLdkc2w2EniUOnRReQ=.5afdce10-f0da-4a19-9f67-492e5d37eeb1@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
 <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>
 <4TNkmn7EQo0ptD0or5DagwYjdjRvnbpPTXGJZyE6D4Y=.4bdd7cf7-b21e-4c40-8ad6-ea96086c017b@github.com>
 <X5_T2W7WfR0HHk1-56XGtop1jOLdkc2w2EniUOnRReQ=.5afdce10-f0da-4a19-9f67-492e5d37eeb1@github.com>
Message-ID: <vuAmJ120l3N6KvV7ABameJZaLIJ-1W3IPOVuLSKFyeQ=.aba175c5-efb6-430f-8708-fd5ee221f7c8@github.com>

On Thu, 6 Mar 2025 01:40:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Marked as reviewed by erikj (Reviewer).
>
> Thanks @erikj79  for the reviews and suggestions.

@sendaoYan I missed commenting on this before it was integrated, but should not these disabled tests be counted under the new "SKIPPED" heading instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/23904#issuecomment-2706474849

From jwaters at openjdk.org  Fri Mar  7 13:46:05 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Mar 2025 13:46:05 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <uTD53V9aGqZELThLytg9BqOOGuuAUnDkoTh5o20AYPc=.621c48f6-78b9-49b4-bbf4-0bef04dc625b@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
 <UZ7o3EbaKrcToWfCY395VnTBwtGPRqTeLVcOqElj1Es=.8ebac174-c9de-4289-a44b-7a05febe252b@github.com>
 <uTD53V9aGqZELThLytg9BqOOGuuAUnDkoTh5o20AYPc=.621c48f6-78b9-49b4-bbf4-0bef04dc625b@github.com>
Message-ID: <rrQ2DSyYQwWJBpRkdqEIIknncKirOCwvPw_9zv9Yjtg=.3ff9dc28-7c13-4c53-b8d2-745caa54b9d7@github.com>

On Fri, 7 Mar 2025 12:00:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Oops, didn't mean to do that. Oh well, will update this again later
>
> @TheShermanTanker This seems like a good fix to make VSC++ behave according to standard. I think it should be resurrected.

@magicus I think this was closed by GitHub itself since I messed up somewhere along the line with switching to a new branch to work on this. I could reopen a new Pull Request, but Daniel's concerns were what prevented me from doing so last time. Also, I think Skara may have a bug, since it seems to think that this closed Pull Request is open now

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706486932

From magnus.ihse.bursie at oracle.com  Fri Mar  7 13:53:50 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 14:53:50 +0100
Subject: Nix shell for building OpenJDK on macOS
In-Reply-To: <CAAcPREssgBjNxtDeeD0S_VGFRjRbX_6mFDUEHrLez7FEZYXTFg@mail.gmail.com>
References: <CAAcPREssgBjNxtDeeD0S_VGFRjRbX_6mFDUEHrLez7FEZYXTFg@mail.gmail.com>
Message-ID: <786e3ed3-4050-43bf-829a-0caf2b7236b9@oracle.com>

Thank you for your report!

I have only touched nix briefly, but it's good to know that they seem to 
have an official jdk package. Maybe we should mention this in the build 
readme as an alternative way to setup a dev environment for the JDK?

/Magnus

On 2025-03-07 14:29, Galder Zamarreno wrote:
> Hi,
>
> The dependencies required to build JDK vary depending on which JDK 
> version you are building. I've been building my own set of scripts 
> that allows me to easily manage this, to the extent that I can do it 
> on the given base OS I run. E.g. if I'm building a mainline I'd use X 
> as boot JDK but if I'm building a JDK 21 backport I'd use Y as boot 
> JDK. These scripts are cumbersome?and they can't control all tooling 
> dependencies, so their use is limited.
>
> In my spare time I've been experimenting with Nix, which offers a 
> declarative way for package management and system configuration. Its 
> package manager can be installed on either Linux or Mac and enables 
> you to start shell instances with a set of isolated dependencies.
>
> I've been wanting to move from my cumbersome scripts to a setup that 
> allows?me to build my local JDKs within a Nix isolated shell. However, 
> although Nix packages exist that build OpenJDK [1], these only support 
> Linux and I'm often developing on a mac. After some exploration, I've 
> been able to craft a Nix descriptor file that allows me to build JDK 
> in an isolated Nix shell on a mac. I wanted to share this in this 
> mailing list in case it is useful to other JDK developers.
>
> The starting point is having a mac devkit. Since I'm not a Nix expert 
> I built it outside of Nix, e.g.
>
> ```
> $ cd jdk/make/devkit
> $ bash ./createMacosxDevkit.sh /Applications/Xcode.app
> ```
>
> Then I added the devkit manually to the Nix store:
>
> ```
> $ cd jdk/build/devkit
> $ nix-store --add-fixed --recursive sha256 Xcode16.2-MacOSX15
> /nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15
> ```
>
> Then I created a shell.nix file that declares the dependencies and 
> sets environment variables to build the JDK successfully. Something 
> that is odd is that if you depend on pkgs.jdk23 on mac, it doesn't 
> throw an error because [1] is not supported there, but it downloads 
> Azul's Zulu JDK. I've asked how this happens [2] but didn't get a 
> satisfactory answer but this is ok for now for a boot jdk. The DEVKIT 
> env variable points to the devkit I added to the nix store and MIGCC 
> is set so that the JDK build?uses the clang from the package dependency.
>
> ```
> { pkgs ? import <nixpkgs> {} }:
>
> let
> ? devkit = 
> "/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15";
> in
> pkgs.mkShell {
> ? packages = [
> ? ? pkgs.autoconf
> ? ? pkgs.jdk23
> ? ? pkgs.clang
>
> ? ? devkit
> ? ];
>
> ? shellHook = ''
> ? ? echo "Setting DEVKIT_ROOT to path of the devkit in the Nix store."
> ? ? export DEVKIT_ROOT=${devkit}
>
> ? ? echo "Setting MIGCC to clang compiler cc binary."
> ? ? export MIGCC="${pkgs.clang}/bin/cc"
> ? '' ;
> }
> ```
>
> From the directory where the shell.nix file is located you can start a 
> Nix shell that will start the isolated environment:
>
> ```
> nix-shell
> ```
>
> In that nix-shell you can now configure the JDK pointing the boot JDK 
> and the devkit:
>
> ```
> [nix-shell: jdk] $ bash configure \
> ? ? --with-boot-jdk=$(dirname $(dirname $(readlink -f $(which java)))) \
> ? ? --with-devkit=$DEVKIT_ROOT
> ```
>
> The configure output looks like this:
>
> ```
> A new configuration has been successfully created in
> /Users/galder/1/colata/nix-darwin/jdk/build/macosx-aarch64-server-release
> using configure arguments 
> '--with-boot-jdk=/nix/store/wm5rma6x2527qmypzj7rwml8vf9vprgj-zulu-ca-jdk-23.0.0/zulu-23.jdk/Contents/Home 
> --with-devkit=/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15'.
>
> Configuration summary:
> * Name: ? ? ? ? ? macosx-aarch64-server-release
> * Debug level: ? ?release
> * HS debug level: product
> * JVM variants: ? server
> * JVM features: ? server: 'cds compiler1 compiler2 dtrace epsilongc 
> g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services 
> shenandoahgc vm-structs zgc'
> * OpenJDK target: OS: macosx, CPU architecture: aarch64, address 
> length: 64
> * Version string: 25-internal-adhoc.galder.jdk (25-internal)
> * Source date: ? ?315532800 (1980-01-01T00:00:00Z)
>
> Tools summary:
> * Boot JDK: ? ? ? openjdk version "23" 2024-09-17 OpenJDK Runtime 
> Environment Zulu23.28+85-CA (build 23+37) OpenJDK 64-Bit Server VM 
> Zulu23.28+85-CA (build 23+37, mixed mode, sharing) (at 
> /nix/store/wm5rma6x2527qmypzj7rwml8vf9vprgj-zulu-ca-jdk-23.0.0/zulu-23.jdk/Contents/Home)
> * Toolchain: ? ? ?clang (clang/LLVM from Xcode 16.2)
> * Devkit: ? ? ? ? Xcode 16.2 (devkit) 
> (/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15)
> * C Compiler: ? ? Version 16.0.0 (at 
> /nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang)
> * C++ Compiler: ? Version 16.0.0 (at 
> /nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++)
>
> Build performance summary:
> * Build jobs: ? ? 14
> * Memory limit: ? 49152 MB
> ```
>
> Then you can just run make and verify the JDK version:
>
> ```
> [nix-shell: jdk] $ make
> ...
> Finished building target 'default (exploded-image)' in configuration 
> 'macosx-aarch64-server-release'
>
> [nix-shell: jdk] $ ./build/macosx-aarch64-server-release/jdk/bin/java 
> --version
> openjdk 25-internal 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.galder.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.galder.jdk, mixed mode)
> ```
>
> The above is sufficient for my own use case, but it can be enhanced 
> further to add capstone dependency...etc.
>
> I don't know who is taking care of [1] but while working on this a 
> member in Nix macos discord asked me to create an issue in Nix 
> packages so that others can maybe take this further and enhance [1] so 
> that it also supports darwin-aarch64. So I created [3].
>
> XCode is tricky to handle, but it would be great if eventually there 
> would be Nix packages for JDK devkits?for macos. If those were 
> available, it would enable OpenJDK developers to build earlier JDK 
> versions even of the very latest macos environments, by depending on 
> earlier XCode version based JDK devkits. You could also pick whichever 
> clang, capstone...etc version that matches that...etc.
>
> Thanks
> Galder
>
> [1] 
> https://github.com/NixOS/nixpkgs/blob/nixos-24.11/pkgs/development/compilers/openjdk/generic.nix
> [2] https://github.com/NixOS/nixpkgs/issues/377908
> [3] https://github.com/NixOS/nixpkgs/issues/387516
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250307/65f5169d/attachment-0001.htm>

From ihse at openjdk.org  Fri Mar  7 15:10:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 15:10:57 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <cTRgAAA0B5QD80WXj4zUi1BqGX7aPtkvRVXMN_BdQ-Y=.b377ddb4-cd40-4480-9237-c68f0cc56b39@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <cvZUOyaUr9G-miDbePX6Tmsum4Y5KMNjpTLKaL1W0Rc=.2096adec-dde0-4936-b18e-2090385b4349@github.com>
 <HcpND1YQVUVwQSHAkJtm0v0zNwDZ7nRhLXW6Z3r0hQk=.b360c659-4103-4280-80dc-b11d2f81f7bb@github.com>
 <ZE8xCvaV43R1NwFC043lKBgz4eOE-2ayAfYPWULRIFY=.aa2c7cc9-dc4e-47a2-973e-a330e0dddee8@github.com>
 <cTRgAAA0B5QD80WXj4zUi1BqGX7aPtkvRVXMN_BdQ-Y=.b377ddb4-cd40-4480-9237-c68f0cc56b39@github.com>
Message-ID: <E3y7XfCv2LH1q7N2zj9ttzU8DinlQZ5sGmblzIGh7OY=.c3f5e69c-5be5-410e-88fd-cb14ed59984f@github.com>

On Fri, 7 Mar 2025 07:21:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It's no that important, no. I'm not sure if previous deprecated ports were handles exactly like this. 
>> 
>> And you can always do like `git log | grep -i "remove .* port"` to find the change it was removed in, and look what it did...
>
> I think leaving a comment describing how to deprecate a port is useful. To look it up in history you have to realise there is something to look up.
> 
> "They who are not reminded of the past will invent a new way to do it in the future."

The `--enable-deprecated-ports` is still there. All that is removed is an if statement and a print line. I know the make syntax can seem intimidating, but just ask me or any other build team member if you need help to recreate such a thing. It is not like it is a complicated algorithm that can be written in many ways. This is just make's equivalant of:


if (some_condition) {
  println("whatever");
}


To me this is just utter nonsense to keep that commented out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1985229429

From ihse at openjdk.org  Fri Mar  7 15:10:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 15:10:59 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <TmaDZUuyHg91WNBqeVOyrxZB5kaX8ogQu9p8Lk03xMQ=.3ccf1de1-c4f3-43fa-b94c-7b8eb86251f4@github.com>

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

make/autoconf/platform.m4 line 669:

> 667:   AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
> 668:       [Suppress the error when configuring for a deprecated port @<:@no@:>@])])
> 669:   # There are no deprecated ports. This option is left to be consistent with future deprecations.

Also, to be clear, we need to keep the option to not break people's scripts. The alternative would be to deprecate the  `--enable-deprecated-ports` arguments, and then remove it in a future release, but I think it is reasonable to keep it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1985232539

From ihse at openjdk.org  Fri Mar  7 15:14:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 15:14:09 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
Message-ID: <ISPINGcBTcDkUB1ZkQMGtrGKCHS5hQqtyLV-PqXoamk=.87c840b9-ca27-466e-9cb6-888f19c2d153@github.com>

On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Was: sunmscapi.dll cannot compile with Visual C++
>> 
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AccessBridgeJavaEntryPoints.cpp

So, Daniel pointed out some irrelevant changes that you tried to sneak in. :) I think he is right that these should be reverted. I don't see anyone complaining about removing `-Zc:wchar_t-` though, or the necessary follow-up fixes for this. 

But this PR has indeed gotten a bit messy, so it's maybe better to open a new and just bring over the relevant fixes.

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706696288

From jwaters at openjdk.org  Fri Mar  7 15:17:19 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Mar 2025 15:17:19 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <ISPINGcBTcDkUB1ZkQMGtrGKCHS5hQqtyLV-PqXoamk=.87c840b9-ca27-466e-9cb6-888f19c2d153@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
 <ISPINGcBTcDkUB1ZkQMGtrGKCHS5hQqtyLV-PqXoamk=.87c840b9-ca27-466e-9cb6-888f19c2d153@github.com>
Message-ID: <nnvJxJ9574F8HwX9bL-K5cnCiKdnwEhj8-sejQNK5Ho=.59a3e194-eb54-4ede-b9d7-e2d37f38c6ec@github.com>

On Fri, 7 Mar 2025 15:11:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> So, Daniel pointed out some irrelevant changes that you tried to sneak in. :) I think he is right that these should be reverted. I don't see anyone complaining about removing `-Zc:wchar_t-` though, or the necessary follow-up fixes for this.
> 
> But this PR has indeed gotten a bit messy, so it's maybe better to open a new and just bring over the relevant fixes.

I don't think Daniel's concerns stopped at the irrelevant changes though. I recall he was worried about removing the switch causing everywhere a jchar is passed to a WINAPI method needing a reinterpret cast, which is dangerous. I still don't know if that concern has been addressed yet

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706705837

From ihse at openjdk.org  Fri Mar  7 15:19:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 15:19:07 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
 <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>
Message-ID: <7lj62NHzOSzqL-1MEvHLg228x2l3rVABVe8weAnA-EQ=.ed5dba84-190a-4204-b80c-b23be62a9dc5@github.com>

On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
>> 
>> Tested on static JDK locally
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161
>
> Thanks for the reviews and historical info!

@jianglizhou I looked at this as part of my backlog, and it struck me that there are several other tests that declare a dependency to java.base:libjvm. Are these working properly on static builds?

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

PR Comment: https://git.openjdk.org/jdk/pull/23835#issuecomment-2706710853

From djelinski at openjdk.org  Fri Mar  7 15:27:08 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Mar 2025 15:27:08 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
Message-ID: <7kBnYGrIMJOk_HHsxrFqkVus4rLt0DkWRLsHyAsMmps=.55561218-81fe-4d28-9ef0-39f837ab84e6@github.com>

On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Was: sunmscapi.dll cannot compile with Visual C++
>> 
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AccessBridgeJavaEntryPoints.cpp

If the changes in this PR are all that is required to enable the option, I think we can live with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706727799

From galder at redhat.com  Fri Mar  7 15:28:10 2025
From: galder at redhat.com (Galder Zamarreno)
Date: Fri, 7 Mar 2025 16:28:10 +0100
Subject: Nix shell for building OpenJDK on macOS
In-Reply-To: <786e3ed3-4050-43bf-829a-0caf2b7236b9@oracle.com>
References: <CAAcPREssgBjNxtDeeD0S_VGFRjRbX_6mFDUEHrLez7FEZYXTFg@mail.gmail.com>
 <786e3ed3-4050-43bf-829a-0caf2b7236b9@oracle.com>
Message-ID: <CAAcPREsr4Y1w9Yezh7kScYsQ6Vgo_pOfDcgvXg3SRUukHEA8Kg@mail.gmail.com>

Yeah we could mention, though I'm not sure what exactly we should say
there. I've only experimented with this on mac so far, but I hope to expand
to linux, in which case I'll see if I can take advantage of the existing
package definition somehow.

Also, you might notice some strange things in my shell.nix. For example, I
got some errors along the way due to Nix trying to use xcrun to locate cc,
which was causing to look it up outside the nix environment. I was able to
quick fix it by using clang package but devkit does bring clang and cc so
it should all be able to resolve from there. So, what I'm trying to say is
that what I shared earlier is not meant to be perfect, but a starting
point, particularly for those on macos. The official jdk Nix packages are
likely more refined and battle tested.

Thanks
Galder


On Fri, Mar 7, 2025 at 2:54?PM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> Thank you for your report!
>
> I have only touched nix briefly, but it's good to know that they seem to
> have an official jdk package. Maybe we should mention this in the build
> readme as an alternative way to setup a dev environment for the JDK?
>
> /Magnus
> On 2025-03-07 14:29, Galder Zamarreno wrote:
>
> Hi,
>
> The dependencies required to build JDK vary depending on which JDK version
> you are building. I've been building my own set of scripts that allows me
> to easily manage this, to the extent that I can do it on the given base OS
> I run. E.g. if I'm building a mainline I'd use X as boot JDK but if I'm
> building a JDK 21 backport I'd use Y as boot JDK. These scripts are
> cumbersome and they can't control all tooling dependencies, so their use is
> limited.
>
> In my spare time I've been experimenting with Nix, which offers a
> declarative way for package management and system configuration. Its
> package manager can be installed on either Linux or Mac and enables you to
> start shell instances with a set of isolated dependencies.
>
> I've been wanting to move from my cumbersome scripts to a setup that
> allows me to build my local JDKs within a Nix isolated shell. However,
> although Nix packages exist that build OpenJDK [1], these only support
> Linux and I'm often developing on a mac. After some exploration, I've been
> able to craft a Nix descriptor file that allows me to build JDK in an
> isolated Nix shell on a mac. I wanted to share this in this mailing list in
> case it is useful to other JDK developers.
>
> The starting point is having a mac devkit. Since I'm not a Nix expert I
> built it outside of Nix, e.g.
>
> ```
> $ cd jdk/make/devkit
> $ bash ./createMacosxDevkit.sh /Applications/Xcode.app
> ```
>
> Then I added the devkit manually to the Nix store:
>
> ```
> $ cd jdk/build/devkit
> $ nix-store --add-fixed --recursive sha256 Xcode16.2-MacOSX15
> /nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15
> ```
>
> Then I created a shell.nix file that declares the dependencies and sets
> environment variables to build the JDK successfully. Something that is odd
> is that if you depend on pkgs.jdk23 on mac, it doesn't throw an error
> because [1] is not supported there, but it downloads Azul's Zulu JDK. I've
> asked how this happens [2] but didn't get a satisfactory answer but this is
> ok for now for a boot jdk. The DEVKIT env variable points to the devkit I
> added to the nix store and MIGCC is set so that the JDK build uses the
> clang from the package dependency.
>
> ```
> { pkgs ? import <nixpkgs> {} }:
>
> let
>   devkit =
> "/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15";
> in
> pkgs.mkShell {
>   packages = [
>     pkgs.autoconf
>     pkgs.jdk23
>     pkgs.clang
>
>     devkit
>   ];
>
>   shellHook = ''
>     echo "Setting DEVKIT_ROOT to path of the devkit in the Nix store."
>     export DEVKIT_ROOT=${devkit}
>
>     echo "Setting MIGCC to clang compiler cc binary."
>     export MIGCC="${pkgs.clang}/bin/cc"
>   '' ;
> }
> ```
>
> From the directory where the shell.nix file is located you can start a Nix
> shell that will start the isolated environment:
>
> ```
> nix-shell
> ```
>
> In that nix-shell you can now configure the JDK pointing the boot JDK and
> the devkit:
>
> ```
> [nix-shell: jdk] $ bash configure \
>     --with-boot-jdk=$(dirname $(dirname $(readlink -f $(which java)))) \
>     --with-devkit=$DEVKIT_ROOT
> ```
>
> The configure output looks like this:
>
> ```
> A new configuration has been successfully created in
> /Users/galder/1/colata/nix-darwin/jdk/build/macosx-aarch64-server-release
> using configure arguments
> '--with-boot-jdk=/nix/store/wm5rma6x2527qmypzj7rwml8vf9vprgj-zulu-ca-jdk-23.0.0/zulu-23.jdk/Contents/Home
> --with-devkit=/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15'.
>
> Configuration summary:
> * Name:           macosx-aarch64-server-release
> * Debug level:    release
> * HS debug level: product
> * JVM variants:   server
> * JVM features:   server: 'cds compiler1 compiler2 dtrace epsilongc g1gc
> jfr jni-check jvmci jvmti management parallelgc serialgc services
> shenandoahgc vm-structs zgc'
> * OpenJDK target: OS: macosx, CPU architecture: aarch64, address length: 64
> * Version string: 25-internal-adhoc.galder.jdk (25-internal)
> * Source date:    315532800 (1980-01-01T00:00:00Z)
>
> Tools summary:
> * Boot JDK:       openjdk version "23" 2024-09-17 OpenJDK Runtime
> Environment Zulu23.28+85-CA (build 23+37) OpenJDK 64-Bit Server VM
> Zulu23.28+85-CA (build 23+37, mixed mode, sharing) (at
> /nix/store/wm5rma6x2527qmypzj7rwml8vf9vprgj-zulu-ca-jdk-23.0.0/zulu-23.jdk/Contents/Home)
> * Toolchain:      clang (clang/LLVM from Xcode 16.2)
> * Devkit:         Xcode 16.2 (devkit)
> (/nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15)
> * C Compiler:     Version 16.0.0 (at
> /nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang)
> * C++ Compiler:   Version 16.0.0 (at
> /nix/store/vhsix1jn849mpxggwbw2zh1nbxpy0grc-Xcode16.2-MacOSX15/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++)
>
> Build performance summary:
> * Build jobs:     14
> * Memory limit:   49152 MB
> ```
>
> Then you can just run make and verify the JDK version:
>
> ```
> [nix-shell: jdk] $ make
> ...
> Finished building target 'default (exploded-image)' in configuration
> 'macosx-aarch64-server-release'
>
> [nix-shell: jdk] $ ./build/macosx-aarch64-server-release/jdk/bin/java
> --version
> openjdk 25-internal 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.galder.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.galder.jdk, mixed mode)
> ```
>
> The above is sufficient for my own use case, but it can be enhanced
> further to add capstone dependency...etc.
>
> I don't know who is taking care of [1] but while working on this a member
> in Nix macos discord asked me to create an issue in Nix packages so that
> others can maybe take this further and enhance [1] so that it also supports
> darwin-aarch64. So I created [3].
>
> XCode is tricky to handle, but it would be great if eventually there would
> be Nix packages for JDK devkits for macos. If those were available, it
> would enable OpenJDK developers to build earlier JDK versions even of the
> very latest macos environments, by depending on earlier XCode version based
> JDK devkits. You could also pick whichever clang, capstone...etc version
> that matches that...etc.
>
> Thanks
> Galder
>
> [1]
> https://github.com/NixOS/nixpkgs/blob/nixos-24.11/pkgs/development/compilers/openjdk/generic.nix
> [2] https://github.com/NixOS/nixpkgs/issues/377908
> [3] https://github.com/NixOS/nixpkgs/issues/387516
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250307/c84ef390/attachment-0001.htm>

From magnus.ihse.bursie at oracle.com  Fri Mar  7 15:49:38 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 16:49:38 +0100
Subject: [Proposal] Add code signing on Windows to the JDK build system
In-Reply-To: <1f1fd802-72e0-4b27-9a77-9d9ed913caf3@oracle.com>
References: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com>
 <b85b8665-2d52-4aa6-ad70-94298cbf10f4@oracle.com>
 <79bc54ec-fd5d-4803-914d-01c64ef88a98@redhat.com>
 <1f1fd802-72e0-4b27-9a77-9d9ed913caf3@oracle.com>
Message-ID: <37182570-6ec8-47cc-8560-b3014f07df2c@oracle.com>

Hi Frederic,

I think your proposal makes sense, and as Erik says, the patch is very 
unobtrusive.

I'm not at all sure if it is even possible, but if the signing logic for 
macOS and Windows can be sort of unified and made more abstract, that 
would certainly be a win.

/Magnus


On 2025-02-26 20:46, Erik Joelsson wrote:
> On 2/26/25 10:40 AM, Frederic Thevenet wrote:
>> Hi Erik,
>>
>> Thanks for your comments.
>>
>> As a matter of fact, we at Red Hat also face similar constraints that 
>> prevent us from being able to sign the files on the machine that 
>> build them (and I suspect this is quite common-place).
>>
>> My initial idea to accommodate that is to have the jdk build invoke a 
>> user supplied script (via a --with configure argument) rather than 
>> having it call signtool directly, so as to provide a way for everyone 
>> to easily plug their specific configuration and logic (in our case, 
>> the script uploads the file to sign to the signing machine and 
>> download it once it is done, in a synchronous fashion).
>>
>> In effect, it's just a hook that is invoked after the native linker 
>> has been called.
>>
>> I have created a PR[1] where you can see what I've done in details.
>
> That's a small and unintrusive solution. Our solution is a lot more 
> involved as I figured I wanted to expose a set of top level "phase" 
> targets for signing for each module, so that building libs or 
> launchers can be done independently from signing (e.g. java.base-libs, 
> java.base-launchers and java.base-sign). This necessitates a separate 
> set of output directories for signed libs and signed launchers, where 
> we first build like normal to the regular output dirs and then the 
> sign target copies and signs binaries into the *-signed outputdirs, 
> and when building jmods, we need to pick up the files from those 
> *-signed directories. It's quite messy, so I've kept it all in our 
> internal makefile extensions. I'm also questioning the usefulness of 
> this flexibility given how much complexity it adds, so your proposal 
> is probably preferred.
>
> That said, I'm wondering if we could make it a bit more generic and 
> not define it as "windows" specific? Then perhaps bake in the macos 
> signing logic into this as well. The default implementation could be 
> using the native OS tools while there is a configure option to 
> completely replace it.
>
> /Erik
>
>>
>> Thanks,
>> Frederic
>>
>> [1] https://github.com/openjdk/jdk/pull/23807
>>
>> On 26/02/2025 15:29, Erik Joelsson wrote:
>>> Hello,
>>>
>>> I think this is a reasonable idea and you are welcome to implement 
>>> it. At Oracle we have been solving this using custom extension 
>>> makefiles. That will unfortunately not change with this proposal as 
>>> our signing process does not involve direct access to the native 
>>> tools of the OS. Perhaps this implementation could be made plug-able 
>>> enough so that we could leverage it, I'm not sure. What I'm trying 
>>> to say is that we are not against this, but we are also not inclined 
>>> to invest resources into it.
>>>
>>> /Erik
>>>
>>> On 2/26/25 12:52 AM, Frederic Thevenet wrote:
>>>> Hi,
>>>>
>>>> I would like to start a discussion about adding built-in support 
>>>> for code signing native executable file and dynamic library on 
>>>> Windows directly as part of the JDK build, in a similar fashion to 
>>>> what already exists for macOS.
>>>>
>>>> Most, if not all vendors already ensure that every native 
>>>> executable files and dynamic libraries that are part of the binary 
>>>> builds of OpenJDK that they distribute to their customers for the 
>>>> Windows platform are digitally signed using a set of Microsoft APIs 
>>>> and tools called Authenticode[1].
>>>>
>>>> Since this is not a part of the existing JDK build system, however, 
>>>> this means that each vendor has had to come up with their own way 
>>>> to integrate the code signing step into their build pipeline.
>>>> As the shape of the JDK binary deliverable evolved to accommodate 
>>>> features like modules, signing binaries as an after-the-fact 
>>>> process has gradually become more complicated and error prone.
>>>>
>>>> For instance, with the introduction of JEP 493 (Linking Run-Time 
>>>> Images without JMODs)[2], adding a digital signature to files after 
>>>> jlink runs as part of the build to create the JDK image when the 
>>>> new '--generate-linkable-runtime' feature is enabled will cause any 
>>>> subsequent uses of jlink from this image to fail with a 
>>>> "Error:<xxxx> has been modified" error.
>>>>
>>>> The solution to that particular problem is to ensure that the 
>>>> signature is applied before jlink generates the checksums it will 
>>>> later use to detect , and I believe the best way to achieve that is 
>>>> to integrate code signing as an option in the jdk build process.
>>>>
>>>> This would also offer vendors who decide to opt into using this new 
>>>> feature to potentially simplify their overall build process.
>>>> For instance, this could get rid of extra steps such as filtering 
>>>> out dlls that are part of the bundle but were not built as part of 
>>>> the jdk (e.g. the Microsoft C and C++ runtime redistributables), or 
>>>> making sure that 'exe' and 'dll' files packaged in the .jmod files 
>>>> are also signed.
>>>>
>>>> As a stated before a very similar option already exists for code 
>>>> signing on the macOS platform, which further reinforce my thinking 
>>>> that such a feature would make sense for Windows as well.
>>>>
>>>> I have drafted a prototype for this and would be happy to create 
>>>> JBS issue and submit a PR to move this forward, provided there is 
>>>> interest.
>>>>
>>>> Thanks,
>>>> Frederic Thevenet (fthevenet)
>>>>
>>>> [1] 
>>>> https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537359(v=vs.85)
>>>> [2] https://openjdk.org/jeps/493
>>>>
>>>
>>

From magnus.ihse.bursie at oracle.com  Fri Mar  7 17:35:50 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 18:35:50 +0100
Subject: Help analyzing output from COMPARE_BUILD
In-Reply-To: <ftepndb6rjvqdvhrdvc5ulku2wwkan5hjhf3qnwwx7amqhcvwg@kgf2jods5omz>
References: <ftepndb6rjvqdvhrdvc5ulku2wwkan5hjhf3qnwwx7amqhcvwg@kgf2jods5omz>
Message-ID: <3e33b514-7829-4c21-8d47-8549e23f9c8a@oracle.com>

This question belongs on build-dev. I've cc:ed that list, please keep 
future discussions there and not in jdk-dev. I'll repsond to your 
question in build-dev.

/Magnus

On 2025-03-07 16:28, Harald Eilertsen wrote:
> Hi,
>
> I've made a small patch to parameterize how support for pthreads is
> enables in the makefiles. This should not make any difference to
> existing builds, but running make with COMPARE_BUILD like this:
>
>      make jdk-image test-image COMPARE_BUILD=PATCH=pthread-diff.patch
>
> I get the following results indicating that there are differences in
> libjvm.so:
>
> https://cryptpad.fr/code/#/2/code/view/t1NVNd5bPzuxVBfEgDKSrt2rLazJaFcFFRimYq6h1-0/
>
> I could use some help analyzing this output.
>
>
> The full patch is here:
>
> https://cryptpad.fr/code/#/2/code/view/2bB0IOCAyG+RZTUSiUQE3g5skfYr2TE7Vx+XYO5a8wY/
>
> The only difference I can see in the generated configure and makefiles
> is the added `LIBPTHREAD` variable in spec.gmk.
>
> Thanks in adcance,
> Harald

From magnus.ihse.bursie at oracle.com  Fri Mar  7 17:40:57 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 18:40:57 +0100
Subject: Help analyzing output from COMPARE_BUILD
In-Reply-To: <3e33b514-7829-4c21-8d47-8549e23f9c8a@oracle.com>
References: <ftepndb6rjvqdvhrdvc5ulku2wwkan5hjhf3qnwwx7amqhcvwg@kgf2jods5omz>
 <3e33b514-7829-4c21-8d47-8549e23f9c8a@oracle.com>
Message-ID: <15ed3b1e-48b7-4281-ac7e-cb0ab04a9bb8@oracle.com>

On 2025-03-07 18:35, Magnus Ihse Bursie wrote:

> This question belongs on build-dev. I've cc:ed that list, please keep 
> future discussions there and not in jdk-dev. I'll repsond to your 
> question in build-dev.
>
> /Magnus
>
> On 2025-03-07 16:28, Harald Eilertsen wrote:
>> Hi,
>>
>> I've made a small patch to parameterize how support for pthreads is
>> enables in the makefiles. This should not make any difference to
>> existing builds, but running make with COMPARE_BUILD like this:
>>
>> ???? make jdk-image test-image COMPARE_BUILD=PATCH=pthread-diff.patch
>>
>> I get the following results indicating that there are differences in
>> libjvm.so:
>>
>> https://cryptpad.fr/code/#/2/code/view/t1NVNd5bPzuxVBfEgDKSrt2rLazJaFcFFRimYq6h1-0/ 
>>
>>
>> I could use some help analyzing this output.

You are seeing some minor variance in the special hotspot gtest library. 
This is known (at least to me :)) to be somewhat flaky, and does not 
always build without differences, even if the rest of the JDK does so. 
These changes are harmless, and are just some kind of offset changes in 
the ELF structure. I guess there is something in the gtest framework 
that triggers this, I just have not figured out what. I have intended to 
dig into it some day, but never gotten around to it.

/Magnus


>>
>>
>> The full patch is here:
>>
>> https://cryptpad.fr/code/#/2/code/view/2bB0IOCAyG+RZTUSiUQE3g5skfYr2TE7Vx+XYO5a8wY/ 
>>
>>
>> The only difference I can see in the generated configure and makefiles
>> is the added `LIBPTHREAD` variable in spec.gmk.
>>
>> Thanks in adcance,
>> Harald

From jiangli at openjdk.org  Fri Mar  7 17:58:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Mar 2025 17:58:52 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <K49N0AawBbmqvKdOTCKXnzRwX-SR4xlcCE4gakuq6DQ=.ed5d34b8-855c-415c-90dd-76077aa60d40@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <tOBM8YCuhkVw2LYOGPMURzJzjl_yFdD-VWz_59PU5sY=.9c267874-ab4e-42df-8202-944600be1794@github.com>
 <olHib3T2rGvzx0Umxn_KJwFFEhu-WWik301Rg-IAUmc=.0bcd6819-b795-4579-becb-75239daf054f@github.com>
 <K49N0AawBbmqvKdOTCKXnzRwX-SR4xlcCE4gakuq6DQ=.ed5d34b8-855c-415c-90dd-76077aa60d40@github.com>
Message-ID: <ioHYjyQT4xRBSI7VzcHUo_3hLfI0GYKro90MIUyYQ9c=.d1878113-f6a7-49ac-ad87-4339757ac154@github.com>

On Fri, 7 Mar 2025 07:41:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > libjsig is provided by JDK.
> 
> Yes for an application to chose to use so that its own signal usage can be better integrated with that of the JDK. Statically linking libjsig with a JDK makes no sense to me at all.

@dholmes-ora Please correct if I'm wrong, I interpret the above as not statically linking libjsig with JDK by default. Leave the decision to the users when building application hermetic/static images according to their usage requirements.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2707064797

From jiangli at openjdk.org  Fri Mar  7 17:58:53 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Mar 2025 17:58:53 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <uJEIBjslJz5K6nXDuqggr68mXEAFo8T3LcPJsZn_84M=.168de488-d1f3-4c12-8d1c-69a91b7f3d6b@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <sSoJ-OWRvapCfaq9rGvJ3UgA85G6UN6psApugzDV6JE=.f76e3338-f525-48b5-9d5c-9bff1cba2f8d@github.com>
 <QXzAD8_S8i8inXeDN8ZxKHgzGocZWhN3lfyPQtO0Ir4=.b518d967-c96b-4842-99d4-ed9a32ffea40@github.com>
 <uJEIBjslJz5K6nXDuqggr68mXEAFo8T3LcPJsZn_84M=.168de488-d1f3-4c12-8d1c-69a91b7f3d6b@github.com>
Message-ID: <WmEUWkhUUsJzLkHefudS0giouXJbR4lsEkx61zB9Wvo=.ea80e78b-bad9-458b-a7fe-b9270901cfe0@github.com>

On Fri, 7 Mar 2025 09:44:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> I meant more like "not supported". You are correct that it is technically possible.
>>> 
>>> How useful is signal chaining even these days?
>>> 
>>> While we could do something like this, I see more trouble ahead. How should we do when we put the static libs in a jmod? Should all static libraries have an "optional/required" flag attached to them? How do the user select if libjsig should be included or not?
>>> 
>>> I would argue that for the time being, it is better to set libjsig as `ONLY_EXPORTED`, and if/when we get back to revisit this, we can start compiling it always, and then we will also have a story on how to test it, how to handle it in jmods, etc, including perhaps a better idea on how important it is to have signal chaining for static builds.
>> 
>> I think I could be convinced, but it probably not a decision could be made by just us. :-) I think it would require broader discussion and decision making on if the JDK signal chaining provided by libjsig should be supported on static JDK. That decision probably should be made as part of a JEP process when we move to that step.
>
>> I meant more like "not supported". You are correct that it is technically possible.
>> 
>> How useful is signal chaining even these days?
>> 
> 
> It is a niche solution to a complex problem (using signals in third-party native libraries which do their signal setup after hotspot signal setup has happened, preventing the library from messing up the hotspot signal mechanism). It is certainly used and needs to continue existing.

@tstuefe Thanks for taking a looking!

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2707066662

From jiangli at openjdk.org  Fri Mar  7 18:33:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Mar 2025 18:33:57 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
 <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>
Message-ID: <Nb4lfm2dNfX3WmFghQr776Qv3NrsYOPrMIGwDgmDwJ4=.161c11d8-0ae8-46a6-bd33-b29dcbffc625@github.com>

On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
>> 
>> Tested on static JDK locally
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161
>
> Thanks for the reviews and historical info!

> @jianglizhou I looked at this as part of my backlog, and it struck me that there are several other tests that declare a dependency to java.base:libjvm. Are these working properly on static builds?

Except `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack`, the other remaining ones in [JtregNativeJdk.gmk](https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/make/test/JtregNativeJdk.gmk#L56),  [JtregNativeLibTest.gmk](https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/make/test/JtregNativeLibTest.gmk#L48) and [JtregNativeHotspot.gmk](https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/make/test/JtregNativeHotspot.gmk#L858) with `java.base:libjvm` dependency are for building test `exe`. We could skip those tests on static JDK until we figure out how we want to support multiple executables. 

`BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack` adds `java.base:libjvm` dependency on Windows only. It might not be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23835#issuecomment-2707127984

From mikael at openjdk.org  Fri Mar  7 22:03:22 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 7 Mar 2025 22:03:22 GMT
Subject: RFR: 8351440: Link with -reproducible on macOS
Message-ID: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>

Background (from JBS):

Recent versions of Xcode, most likely starting with Xcode 15, do not produce deterministic binaries/libraries out of the box. In particular, the UUID data in the LC_UUID load command is not stable.

After spending some significant time trying to understand why, it turns out that the linker has started including the last modified time stamp of the object files in the (debug?) data and that time stamp data is included in the computed UUID "hash". So even if the rest of the data is the same between two builds, the build time (or, more accurately, the time when the object file gets written to the file system) now affects the UUID and therefore the data of the resulting .dylib files.

It seems (unconfirmed) like this may be an artifact of Xcode 15 using a new linker ("ld-prime") which may or may not be why the behavior has changed.

After spending even more time trying to understand what to do about it I noticed this in the ld man page:

     -reproducible
             By default output content will be deterministic, but small changes in input files such as a compilation time might affect certain data structures in the linked binary. This option instructs ld to create a reproducible output binary by ignoring certain input properties or using alternative algorithms.

And, adding that flag (-Wl,-reproducible to clang) does indeed seem to solve the issue.

Testing:

* Manual verification with both Xcode14.3.1 and Xcode 15.4
* tier1,builds-tier[2-5]

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

Commit messages:
 - 8351440: Link with -reproducible on macOS

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

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

From duke at openjdk.org  Sat Mar  8 13:39:44 2025
From: duke at openjdk.org (snake66)
Date: Sat, 8 Mar 2025 13:39:44 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

snake66 has updated the pull request incrementally with three additional commits since the last revision:

 - Use shell var syntax in libraries.m4
 - Fix typo PTREAD->PTHREAD
 - Revert changes to make/Hsdis.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23930/files
  - new: https://git.openjdk.org/jdk/pull/23930/files/6a2c0e53..46999723

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

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

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

From syan at openjdk.org  Sat Mar  8 13:58:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 8 Mar 2025 13:58:03 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v3]
In-Reply-To: <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
 <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>
Message-ID: <9UFdT-v-9fSiAc2xdLacWIl73p51u3gevDuuXSNN6IA=.3fc868ee-04e5-49e1-b666-e2a74d51672c@github.com>

On Wed, 5 Mar 2025 02:10:34 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR fix the makefile bug when there is no gtest 'disable tests' then report syntax error.
>> 
>> Before this PR makefile used below command to get the 'disable tests' number, when there is no 'YOU HAVE [0-9]+ DISABLED TEST' string line in gtest result file gtest.txt, this gawk command will not print anything, so shell report syntax error later.
>> 
>> 
>> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } if (!found) { print 0; } }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
>> 
>> 
>> After this PR makefile will use below command to get the 'disable tests' number.
>> 
>> 
>> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } } END { if (!found) print 0; }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
>> 
>> 
>> Additional testing:
>> 
>> - [x] make test TEST=gtest:Align > test-Alian.log, which return 0 disable test
>> - [x] time make test TEST=gtest > test-all.log, which return 15 disable tests
>> 
>> [test-all.log](https://github.com/user-attachments/files/19074190/test-all.log)
>> [test-Alian.log](https://github.com/user-attachments/files/19074189/test-Alian.log)
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert regex change in if expr

> * time make test TEST=gtest
I don't quite understand your question. This PR do not change the count logic and test result logic. The test report summary show as:


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
   gtest:all/server                                   1101  1086     0     0    15   
==============================
TEST SUCCESS

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

PR Comment: https://git.openjdk.org/jdk/pull/23904#issuecomment-2708297287

From duke at openjdk.org  Sat Mar  8 16:02:07 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sat, 8 Mar 2025 16:02:07 GMT
Subject: RFR: 8351399: AIX: Better solution than JDK8348663
In-Reply-To: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
References: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
Message-ID: <s3kq2EKuBxGKIbqRUlN8kOLzipnj1NXKA88xQIzK7Fc=.99033297-282c-4ec2-9849-3c123cb97382@github.com>

On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search libraries the clang compiler automatically burns into the executable files.
> Now we have a better solution, using just a different linker flag.
> Instead of using the linker option -bnolibpath, which forces the LIBPATH env variable to be burned in, we now use the -blibpath:/usr/lib:lib option, which explicitly tells what to burn in.
> I will revert the last change of [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) and introduce this new change.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23942#pullrequestreview-2669217057

From eirbjo at openjdk.org  Sat Mar  8 18:32:52 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 8 Mar 2025 18:32:52 GMT
Subject: RFR: 8351399: AIX: Better solution than JDK8348663
In-Reply-To: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
References: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
Message-ID: <cchSqR7LURsBY-82lzbyxi7kiLdaHfMTTw3hnP-4G4Y=.5cd47144-3e4c-44a4-9369-534de771480d@github.com>

On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search libraries the clang compiler automatically burns into the executable files.
> Now we have a better solution, using just a different linker flag.
> Instead of using the linker option -bnolibpath, which forces the LIBPATH env variable to be burned in, we now use the -blibpath:/usr/lib:lib option, which explicitly tells what to burn in.
> I will revert the last change of [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) and introduce this new change.

I think it would be nice to rename the PR/JBS title here to something more descriptive and self-contained.

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

PR Comment: https://git.openjdk.org/jdk/pull/23942#issuecomment-2708433741

From duke at openjdk.org  Mon Mar 10 08:50:01 2025
From: duke at openjdk.org (Paul Woegerer)
Date: Mon, 10 Mar 2025 08:50:01 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <qrKql-eXWcuqGXg57SMHLgW4c6fu62bWr4-GCig9VPU=.aae9bd61-0ee6-4950-894b-7e8aeccf67ac@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <p6S-uNlOnLC9lqyJ4LhelYM0tjAu9wc3Xan2ULf9vPE=.05406ef1-8313-4cf5-ac46-3281edadbb82@github.com>
 <GC06yaeFbz0HY6-P4IH2qMT99jlUBAkvCoiV8lOzbx4=.0d4f63f6-c64c-4734-8aa6-9f8e041021f3@github.com>
 <qrKql-eXWcuqGXg57SMHLgW4c6fu62bWr4-GCig9VPU=.aae9bd61-0ee6-4950-894b-7e8aeccf67ac@github.com>
Message-ID: <seMJDjw93dRdusaomt4vnhTT5jp135K5tcwxtdl-Kjo=.fabcc555-6d64-4e83-8cf6-db202c0253cb@github.com>

On Fri, 7 Mar 2025 09:22:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>>> It seems we agree that we need, at some point, to have a high-level discussion on if libjsig should be supported on static builds, and if so, how it should be implemented. We also agree that having signal chaining enabled by default on our static JDK builds are incorrect.
>> 
>> Thumbs up.
>> 
>>> 
>>> However, I suggest we chose a simple path, were we utilize the framework for not building a static library that we do not use (this is already done for several libraries that are not included in the static JDK image), while you suggest we keep compiling it, even if we do not include it and test it.
>>> 
>>> I don't get the point of this. If we don't include it, and don't test it, then surely it would be better to not even build it now?
>> 
>> We have no current usages of libjsig in our current hermetic Java testing and prototype development work. So I don't have related concerns if don't produce a `libjsig.a` in the `static-libs` for the short term. Let's check with @dougxc and others from GraalVM side to make sure that they are okay with removing `libjsig.a` from the static libs bundle, before making any changes.
>
>> Let's check with @dougxc and others from GraalVM side
> 
> @wirthi or someone from the Native Image team will comment on this. Thanks for the heads up.

> Let's check with @dougxc and others from GraalVM side to make sure that they are okay with removing libjsig.a from the static libs bundle, before making any changes.

Hi @jianglizhou,

Native image has no use for `libjsig.a` and we are fine if it is not part of static libs bundle.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2709827155

From duke at openjdk.org  Mon Mar 10 09:03:40 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 10 Mar 2025 09:03:40 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
In-Reply-To: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
Message-ID: <w4waTslggnGRaq3DpeRRONQacG07BsjbUqIuHMkdxgk=.acd35ecb-1b6c-4ff3-9504-63cbd66f5bba@github.com>

On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.

Thank you both for your input. I added an editorconfig locally because because I have other defaults for C++, so my editor can switch to "JDK mode" when working in this project. I put the file into my local .gitignore but thought this might make sense to have it in the repo. Then I found the JBS issue and opened the PR to get the ball rolling.

> The `indent_brace_style` isn't listed as an official property of EditorConfig

You are right. It seems to be only some extension proposal. I removed it.

> What does `indent_style = tab` actually mean for makefiles? [...]

I agree, this seems unnecessary. I also removed this part.


As for the coding style (indentation), I followed the official style guides to define this. 

For C++ we have <https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#whitespace>

which states:
> Indentation levels are two columns.

and

> Tabs are not allowed in code.

so the given config seemed a logical result.

For Java I referred to this <https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html> which states:

> Four spaces should be used as the unit of indentation. The exact construction of the indentation (spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4).

To be honest, this is a bit unclear to me. So maybe I got it wrong in defining 4 spaces here.



I guess the question is: are these guidelines obligatory and if so why can we not define this in an editorconfig?


EDIT:
I would not see much sense in only adding the `trim_trailing_whitespace` option. Then vital settings are missing and I have a file that conflicts with my local one :)

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2709852460

From duke at openjdk.org  Mon Mar 10 09:03:40 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 10 Mar 2025 09:03:40 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v2]
In-Reply-To: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
Message-ID: <D9lRzu4iiDwQdaf_K5nhrrjDX5GdSnTd7nGK0qAQzOQ=.89507c17-765d-4c26-ab2e-a16d085ef48b@github.com>

> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.

David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:

  simplify editorconfig

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23693/files
  - new: https://git.openjdk.org/jdk/pull/23693/files/02f923e2..349997a8

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

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

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

From jkern at openjdk.org  Mon Mar 10 09:09:07 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 10 Mar 2025 09:09:07 GMT
Subject: Integrated: 8351399: AIX: clang pollutes the burned-in library search
 paths of the generated executables / Second try with a better
 solution than JDK8348663
In-Reply-To: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
References: <V4QOrTBWJMhSzq84Q8iPmgQrMVetToywoHCH3lT7vTM=.634234eb-e74b-4b09-9537-2bee6de1f6ec@github.com>
Message-ID: <NRD9e5XPRPEYOBZKjXXio-_B8yXL0FoG7TMZeoNfcUI=.42c68d00-ffec-4a8e-8c26-4f8723771b79@github.com>

On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search libraries the clang compiler automatically burns into the executable files.
> Now we have a better solution, using just a different linker flag.
> Instead of using the linker option -bnolibpath, which forces the LIBPATH env variable to be burned in, we now use the -blibpath:/usr/lib:lib option, which explicitly tells what to burn in.
> I will revert the last change of [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) and introduce this new change.

This pull request has now been integrated.

Changeset: 18931d05
Author:    Joachim Kern <jkern at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18931d05877a69c9d35ac0706d61f9db03875afc
Stats:     35 lines in 3 files changed: 0 ins; 33 del; 2 mod

8351399: AIX: clang pollutes the burned-in library search paths of the generated executables / Second try with a better solution than JDK8348663

Reviewed-by: stuefe, mdoerr, ihse

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

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

From shade at openjdk.org  Mon Mar 10 09:41:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 09:41:01 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
In-Reply-To: <tiENJY_-jSu6BwPzkT8JiK551kqwT8wiK3gGcl3VFhg=.6b7fc9d0-7a11-40ae-ab4a-1f555157c653@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com>
 <xKHhFYIxvCv8mkElhDeTpHcor35FkV9QdWLI0qY_SQc=.1b97dabc-fa7d-4940-bdfa-4e4915901c35@github.com>
 <vc_8BUQmGlQ49NItxWj8XCcs-NyifesE-ZqOYVGF8t8=.a345a768-d087-402a-bbb2-91430778573c@github.com>
 <tiENJY_-jSu6BwPzkT8JiK551kqwT8wiK3gGcl3VFhg=.6b7fc9d0-7a11-40ae-ab4a-1f555157c653@github.com>
Message-ID: <5PZgChiJciTkkZIUnXtTWZMB4ZxN8DmZHUWBFt9ptBw=.77216c80-a470-4e20-908e-7e419404e607@github.com>

On Fri, 7 Mar 2025 07:18:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> You could add a couple of lines to the build code and it would not be possible to build 32-bit, so that is a necessary but not sufficient condition to claim to implement the JEP IMO.

Agreed. This is why this PR removes the actual implementation of the port as well. Even if you can coerce build system to pass the arch checks, x86_32 would not build, because there is no x86_32 port in the sources anymore. There are only assorted, heavily-intertwined-with-x86-64 leftovers around Hotspot subsystems that were needed to support the port. We will deal with those leftovers at leisurely pace after the port is gone.

> @dholmes-ora: I'm not looking for one big PR, I'm looking for multiple PR's as proposed but which all fall under the JEP umbrella. Until the JEP is targeted then nothing can be integrated anyway. This is what, I thought, dependent PR's were designed for.
> @magicus  Instead, that honor should fall on an umbrella JBS issue, which is dependent on this PR, but also the other planned updates. Before these are done, we can't really say that the JEP is implemented.

I believe we are in agreement that we do not want to cobble all removals/cleanups into a singular PR/changeset. We _can_ convert the umbrella RFE for post-JEP cleanups as the implementation task subtasks. I.e. do:

 - JDK-XXXXX: Implement JEP 503: Remove the 32-bit x86-port (<---- this would be an umbrella, without a changeset)
    - JDK-XXXXX: JEP 503: Remove the x86_32 files and builds support (<---- this would be this PR)
    - JDK-XXXXX: JEP 503: Remove code blocks that handle UseSSE < 2
    - JDK-XXXXX: JEP 503: Remove dead IA32 code blocks
    ...

Then we manually close umbrella issue as "implemented" when subtasks are done. 

What I dislike about this approach is that we are committing to doing free-standing post- x86-32 cleanups under the JEP umbrella. This runs into several problems: a) some cleanups are very deep, intertwined with x86-64, connected to x86-32-zero, and might even be rejected, like deep cleaning in `MacroAssembler` ([JDK-8351162](https://bugs.openjdk.org/browse/JDK-8351162)); b) some cleanups would only be discovered later, and would require yet another umbrella tasks for post-JEP work anyway.

Are you agreeing to this, @dholmes-ora, @magicus? This would create more work for ourselves and our fellow engineers in JDK 25 timeframe. If you are insisting we need to do it this way, can I count on your prompt reviews in these new JEP subtasks?

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2709964337

From shade at openjdk.org  Mon Mar 10 09:49:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 09:49:44 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]
In-Reply-To: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
Message-ID: <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

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

 - Drop commented out block from deprecations
 - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone
 - Generic 32-bit x86 configure error supercedes Windows 32-bit x86
 - 8345169: Implement JEP 503: Remove the 32-bit x86 Port

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23906/files
  - new: https://git.openjdk.org/jdk/pull/23906/files/b76816cb..0fef97b8

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

  Stats: 7320 lines in 306 files changed: 3971 ins; 1797 del; 1552 mod
  Patch: https://git.openjdk.org/jdk/pull/23906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23906/head:pull/23906

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

From shade at openjdk.org  Mon Mar 10 09:49:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 09:49:44 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]
In-Reply-To: <E3y7XfCv2LH1q7N2zj9ttzU8DinlQZ5sGmblzIGh7OY=.c3f5e69c-5be5-410e-88fd-cb14ed59984f@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <cvZUOyaUr9G-miDbePX6Tmsum4Y5KMNjpTLKaL1W0Rc=.2096adec-dde0-4936-b18e-2090385b4349@github.com>
 <HcpND1YQVUVwQSHAkJtm0v0zNwDZ7nRhLXW6Z3r0hQk=.b360c659-4103-4280-80dc-b11d2f81f7bb@github.com>
 <ZE8xCvaV43R1NwFC043lKBgz4eOE-2ayAfYPWULRIFY=.aa2c7cc9-dc4e-47a2-973e-a330e0dddee8@github.com>
 <cTRgAAA0B5QD80WXj4zUi1BqGX7aPtkvRVXMN_BdQ-Y=.b377ddb4-cd40-4480-9237-c68f0cc56b39@github.com>
 <E3y7XfCv2LH1q7N2zj9ttzU8DinlQZ5sGmblzIGh7OY=.c3f5e69c-5be5-410e-88fd-cb14ed59984f@github.com>
Message-ID: <3jbKFXHYH2mgyYOQjn2rfGm0IpIwH377DuDrZAY4X7w=.8d0767f3-7190-4396-824a-d55e6a61f479@github.com>

On Fri, 7 Mar 2025 15:06:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I think leaving a comment describing how to deprecate a port is useful. To look it up in history you have to realise there is something to look up.
>> 
>> "They who are not reminded of the past will invent a new way to do it in the future."
>
> The `--enable-deprecated-ports` is still there. All that is removed is an if statement and a print line. I know the make syntax can seem intimidating, but just ask me or any other build team member if you need help to recreate such a thing. It is not like it is a complicated algorithm that can be written in many ways. This is just make's equivalant of:
> 
> 
> if (some_condition) {
>   println("whatever");
> }
> 
> 
> To me this is just utter nonsense to keep that commented out.

"Utter nonsense" might be a bit harsh. We do code samples around OpenJDK all the time to leave breadcrumbs for future use. As I said, I don't mind removing it, done so in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1986943830

From alanb at openjdk.org  Mon Mar 10 09:52:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Mar 2025 09:52:54 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]
In-Reply-To: <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
Message-ID: <8GSZRPDK4WLn6bHC2D2Ow47a-xd9NzCN6azXs2aDp_g=.47762983-f579-4ea1-b22e-abbd1740e6d3@github.com>

On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>> 
>> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
>> 
>> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
>> 
>> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Drop commented out block from deprecations
>  - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone
>  - Generic 32-bit x86 configure error supercedes Windows 32-bit x86
>  - 8345169: Implement JEP 503: Remove the 32-bit x86 Port

JEP 486 (Permanently Disable the Security Manager) updated the API and removed the ability to set a SecurityManager in a first big commit. The JBS issue for that commit was associated with the JEP. There were 150+ follow on issues, some removed essentially dead code, others fixed or removed tests that were excluded by the first commit. It wasn't initially clear if all cleanups and code removal could be done in the same release (JDK 24) but almost all did happen as only a few remaining cleanups to APIs docs spilled over into JDK 25.  Anyway, just pointing out this JEP as an example that may be useful to look at when considering the approach for the 32-bit x86 port removal.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2709998166

From ihse at openjdk.org  Mon Mar 10 10:46:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 10:46:55 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]
In-Reply-To: <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
Message-ID: <hnEmKWRBOyIIbEiVDMUO0nrlmUfkv8xyTvjin4wlQk4=.f03e9f88-e04f-4fdb-9e6f-b31d74f2da04@github.com>

On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>> 
>> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
>> 
>> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
>> 
>> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Drop commented out block from deprecations
>  - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone
>  - Generic 32-bit x86 configure error supercedes Windows 32-bit x86
>  - 8345169: Implement JEP 503: Remove the 32-bit x86 Port

I don't have a super strong opinion on this. If you want to call this the implementation of JEP 503, I'm fine with that. 

I guess it all depends a bit on where you want to draw the line between "removal" and "subsequent cleanups that have now been possible". The latter part almost never ends in a codebase as large as the JDK; I still find Solaris remnants in the code to this day, so getting rid of *all* code that is no longer necessary cannot reasonably be a criterion for finishing a removal.

I guess I just viewed the intertwined ifdef:ed code as more part of the actual removal, but then again, it's Hotspot code and that's strictly really not my business. :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2710148614

From kbarrett at openjdk.org  Mon Mar 10 10:56:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 10 Mar 2025 10:56:53 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v2]
In-Reply-To: <D9lRzu4iiDwQdaf_K5nhrrjDX5GdSnTd7nGK0qAQzOQ=.89507c17-765d-4c26-ab2e-a16d085ef48b@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <D9lRzu4iiDwQdaf_K5nhrrjDX5GdSnTd7nGK0qAQzOQ=.89507c17-765d-4c26-ab2e-a16d085ef48b@github.com>
Message-ID: <PJzG5aYpm269BE5hr3RgPEuDHNjo6n6mZSkoBBFC90A=.c9eca5ec-3ac3-4406-934e-7a059255ec73@github.com>

On Mon, 10 Mar 2025 09:03:40 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify editorconfig

.editorconfig line 8:

> 6: [*.{cpp,hpp,c,h,cc,hh}]
> 7: indent_style = space
> 8: indent_size = 2

The HotSpot style guide prescribes 2 space indentation.  The rest of the JDK not so much, and
counterexamples abound.  For example, java.base/*/native looks to be 4 space indentation
(consistently? I only spot-checked).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23693#discussion_r1987049051

From ihse at openjdk.org  Mon Mar 10 11:03:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:03:04 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
In-Reply-To: <w4waTslggnGRaq3DpeRRONQacG07BsjbUqIuHMkdxgk=.acd35ecb-1b6c-4ff3-9504-63cbd66f5bba@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <w4waTslggnGRaq3DpeRRONQacG07BsjbUqIuHMkdxgk=.acd35ecb-1b6c-4ff3-9504-63cbd66f5bba@github.com>
Message-ID: <byXs11URe09inFX1QduuChNUEqTJ0fnzJi7D9AmidXo=.a2a686a4-1e8b-49d5-b1fe-d464c4079022@github.com>

On Mon, 10 Mar 2025 08:57:11 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> I guess the question is: are these guidelines obligatory and if so why can we not define this in an editorconfig?

No, they are not. That's kind of the crux of the problem. 
* The Hotspot guidelines are followed to a great extent, but I'm pretty sure they also say something along the lines of  "if old code does not adhere to this, do not change everything blindly", which is exactly what an editor would do. 
* Hotspot is not the only C++ code in the JDK; and the rest of the native libraries has nothing even close to the Hotspot guidelines. Furthermore, there are imported 3rd party sources in the code base that are exempt from any kind of requirements.
* The Java guidelines, how official they may look, is not considered really applicable to the JDK code. I *guess* most Java code uses four spaces of indentation, but it is not a clear rule.

> I would not see much sense in only adding the trim_trailing_whitespace option. Then vital settings are missing and I have a file that conflicts with my local one :)

I apologize if such a solution would cause a conflict for your setup, but I seriously think that this is the only way forward. We can setup an editorconfig file that matches what jcheck already checks for, but not anything more. Then we can work on, going forward, to increase the official rules about code. That would allow jcheck to test for more aspects, and an editorconfig to be more explicit.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2710191786
PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2710196397

From ihse at openjdk.org  Mon Mar 10 11:05:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:05:56 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <Cd4HwT3pkU_8EsRHOszo9birQoXmCWbEhqAo1kPeCRw=.28bcd601-1d63-499c-8c83-136cef08fb77@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

With that confirmation, I think we should go on with the `ONLY_EXPORTED` solution instead. 

If needed, we can revisit this in the future, to discuss how we should handle an optional library like libjsig. But that requires a complete solution througout the jmod/jlink pipeline to be meaningful.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2710203413

From kbarrett at openjdk.org  Mon Mar 10 11:06:00 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 10 Mar 2025 11:06:00 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
In-Reply-To: <w4waTslggnGRaq3DpeRRONQacG07BsjbUqIuHMkdxgk=.acd35ecb-1b6c-4ff3-9504-63cbd66f5bba@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <w4waTslggnGRaq3DpeRRONQacG07BsjbUqIuHMkdxgk=.acd35ecb-1b6c-4ff3-9504-63cbd66f5bba@github.com>
Message-ID: <G-CO446PHPAvjQeYxlSe4W_qQF5ACL7F3tFq7ibQvZ4=.154fbb1f-62bc-4228-8c07-c64cae293349@github.com>

On Mon, 10 Mar 2025 08:57:11 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> As for the coding style (indentation), I followed the official style guides to define this.
> 
> For C++ we have https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#whitespace
> 
> which states:
> 
> > Indentation levels are two columns.

The HotSpot Style Guide applies to HotSpot native code.  It doesn't apply to native code in the rest of the JDK.
(For one thing, HotSpot is (almost?) entirely C++, while much of the native code in the rest of the JDK is C.
And even a casual perusal will find large swaths of HSG violations in non-HotSpot code.)

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2710204389

From ihse at openjdk.org  Mon Mar 10 11:06:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:06:58 GMT
Subject: RFR: 8351138: Running subset of gtests gets error printing result
 information [v3]
In-Reply-To: <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>
References: <B03r9O5YLavxVrbMwoIufApcuHWk5abJqs7S-PNgaN0=.798c4cc8-9342-4337-88f1-3b9291b021b3@github.com>
 <FzVhPC9LNLPPyqLzFET1gq-T3DL05zNMtJyBnD_Q1BU=.da9f3b67-fedb-47a8-a6ea-410099884272@github.com>
Message-ID: <ba85qswWoN65xyB3kWn65L35Mzd5sgNoy3C00Kfiy4s=.2e71caa1-16a3-40e5-a080-cb9ca1881c91@github.com>

On Wed, 5 Mar 2025 02:10:34 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR fix the makefile bug when there is no gtest 'disable tests' then report syntax error.
>> 
>> Before this PR makefile used below command to get the 'disable tests' number, when there is no 'YOU HAVE [0-9]+ DISABLED TEST' string line in gtest result file gtest.txt, this gawk command will not print anything, so shell report syntax error later.
>> 
>> 
>> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } if (!found) { print 0; } }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
>> 
>> 
>> After this PR makefile will use below command to get the 'disable tests' number.
>> 
>> 
>> gawk '/YOU HAVE [0-9]+ DISABLED TEST/ { if (match($0, /[0-9]+/, arr)) { print arr[0]; found=1; } } END { if (!found) print 0; }' build/linux-x86_64-server-release/test-results/gtest_Align_server/gtest.txt
>> 
>> 
>> Additional testing:
>> 
>> - [x] make test TEST=gtest:Align > test-Alian.log, which return 0 disable test
>> - [x] time make test TEST=gtest > test-all.log, which return 15 disable tests
>> 
>> [test-all.log](https://github.com/user-attachments/files/19074190/test-all.log)
>> [test-Alian.log](https://github.com/user-attachments/files/19074189/test-Alian.log)
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert regex change in if expr

Okay, then it's all fine. I misunderstood the code and your patch. Thank you, and apologies.

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

PR Comment: https://git.openjdk.org/jdk/pull/23904#issuecomment-2710207110

From ihse at openjdk.org  Mon Mar 10 11:09:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:09:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <2Q8X64gNkTwIahuYztjcdmNpOiwF9imTIUUI-0ASx4k=.4ba096ff-d60b-46fd-93ce-33215b0bc650@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

This looks good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2670569844

From ihse at openjdk.org  Mon Mar 10 11:09:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:09:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: <fW2QbW1i6Z-yKZaK2UhG5fn-SMbZ7QbX0DQQ4KC4x4w=.85a1740c-d82d-4681-bebf-bc5961a47c3c@github.com>

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

Another follow-up is if it would hurt to include $LIBPTHREAD for *all* Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2710217007

From ihse at openjdk.org  Mon Mar 10 11:13:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:13:02 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <xkrLjELwIEqijtebFGcQzVvj5pIManAq7LrAAkQAJ6k=.b56fc428-c733-4878-8d28-39d7a9063e27@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

Okay, great! I did not notice it was for exe's, I just grepped quickly for `libjvm`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23835#issuecomment-2710224648

From matthias.baesken at sap.com  Mon Mar 10 12:02:28 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 10 Mar 2025 12:02:28 +0000
Subject: LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug
 symbols
Message-ID: <AM9PR02MB6770E7A120A769AAC04830FC93D62@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hello, while looking at the JDK native lib optimization levels, I noticed this special setting :

make/modules/java.management/Lib.gmk

ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
   LIBMANAGEMENT_OPTIMIZATION := LOW
endif

Why is it there ?
I removed it  in out internal tests and saw no issues.
Do we still need it these days ? Was it maybe done for very old  gcc versions ?


Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250310/18720134/attachment-0001.htm>

From coleenp at openjdk.org  Mon Mar 10 12:30:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Mar 2025 12:30:59 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]
In-Reply-To: <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
Message-ID: <WZT7AquZiPC0uiZzXM5SJYZDSfREihH1Y66we498K5o=.2969e96a-3e25-4f24-ba72-d6a1416f1363@github.com>

On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>> 
>> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
>> 
>> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
>> 
>> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Drop commented out block from deprecations
>  - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone
>  - Generic 32-bit x86 configure error supercedes Windows 32-bit x86
>  - 8345169: Implement JEP 503: Remove the 32-bit x86 Port

Marked as reviewed by coleenp (Reviewer).

I do have a strong opinion on this.  The security manager removal is a good model to follow. Since this change removes the capability and 50K LOC, I think it's sufficient to say it implements the JEP.  The other removals are cleanups and don't need to have to be tied up in the process, and can happen when they're ready and reviewed.  There's no technical or practical reason to make this more difficult.

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

PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2670782075
PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2710418458

From erikj at openjdk.org  Mon Mar 10 12:51:03 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 12:51:03 GMT
Subject: RFR: 8351440: Link with -reproducible on macOS
In-Reply-To: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>
References: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>
Message-ID: <hMeq8xbs1nmzWT371lmqsfauqd84nFBcPpQhSXYKBtA=.781b728c-2be9-4ec3-ac74-3c952784c284@github.com>

On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> Recent versions of Xcode, most likely starting with Xcode 15, do not produce deterministic binaries/libraries out of the box. In particular, the UUID data in the LC_UUID load command is not stable.
> 
> After spending some significant time trying to understand why, it turns out that the linker has started including the last modified time stamp of the object files in the (debug?) data and that time stamp data is included in the computed UUID "hash". So even if the rest of the data is the same between two builds, the build time (or, more accurately, the time when the object file gets written to the file system) now affects the UUID and therefore the data of the resulting .dylib files.
> 
> It seems (unconfirmed) like this may be an artifact of Xcode 15 using a new linker ("ld-prime") which may or may not be why the behavior has changed.
> 
> After spending even more time trying to understand what to do about it I noticed this in the ld man page:
> 
>      -reproducible
>              By default output content will be deterministic, but small changes in input files such as a compilation time might affect certain data structures in the linked binary. This option instructs ld to create a reproducible output binary by ignoring certain input properties or using alternative algorithms.
> 
> And, adding that flag (-Wl,-reproducible to clang) does indeed seem to solve the issue.
> 
> Testing:
> 
> * Manual verification with both Xcode14.3.1 and Xcode 15.4
> * tier1,builds-tier[2-5]

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23949#pullrequestreview-2670834186

From ihse at openjdk.org  Mon Mar 10 12:57:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 12:57:57 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]
In-Reply-To: <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
Message-ID: <D6jopGF4Rx4Ont1iY3xgOVWFHePpLz4TZrunRsIdl04=.b52995da-572f-4150-b09b-df62bf43c665@github.com>

On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>> 
>> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
>> 
>> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
>> 
>> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Drop commented out block from deprecations
>  - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone
>  - Generic 32-bit x86 configure error supercedes Windows 32-bit x86
>  - 8345169: Implement JEP 503: Remove the 32-bit x86 Port

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2670852740

From erikj at openjdk.org  Mon Mar 10 13:01:59 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 13:01:59 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
In-Reply-To: <G-CO446PHPAvjQeYxlSe4W_qQF5ACL7F3tFq7ibQvZ4=.154fbb1f-62bc-4228-8c07-c64cae293349@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <w4waTslggnGRaq3DpeRRONQacG07BsjbUqIuHMkdxgk=.acd35ecb-1b6c-4ff3-9504-63cbd66f5bba@github.com>
 <G-CO446PHPAvjQeYxlSe4W_qQF5ACL7F3tFq7ibQvZ4=.154fbb1f-62bc-4228-8c07-c64cae293349@github.com>
Message-ID: <EmLzyTsppZoMu2aek9S61hd_WadzQHHbW6FtRPrCN5Q=.b520f75c-6421-45a8-bc0a-c22229970bb6@github.com>

On Mon, 10 Mar 2025 11:03:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > As for the coding style (indentation), I followed the official style guides to define this.
> > For C++ we have https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#whitespace
> > which states:
> > > Indentation levels are two columns.
> 
> The HotSpot Style Guide applies to HotSpot native code. It doesn't apply to native code in the rest of the JDK. (For one thing, HotSpot is (almost?) entirely C++, while much of the native code in the rest of the JDK is C. And even a casual perusal will find large swaths of HSG violations in non-HotSpot code.)

We could consider adding a separate .editorconfig file in `src/hotspot` with these C++ rules.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2710518183

From erikj at openjdk.org  Mon Mar 10 13:04:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 13:04:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <9NJh2NWuQ_op9oUEpq2qS-64TpkGnIXaT54pdIV8amI=.e65c76d6-bb81-4ce0-b3ee-5d8c975b6ac5@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2670880262

From ihse at openjdk.org  Mon Mar 10 13:11:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 13:11:58 GMT
Subject: RFR: 8351440: Link with -reproducible on macOS
In-Reply-To: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>
References: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>
Message-ID: <SbFNSHNTUZLbNESuTD1ex3jBjtMzW3TLhV5OwbFHWxY=.aad53f93-6328-41fe-8201-12548468e193@github.com>

On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> Recent versions of Xcode, most likely starting with Xcode 15, do not produce deterministic binaries/libraries out of the box. In particular, the UUID data in the LC_UUID load command is not stable.
> 
> After spending some significant time trying to understand why, it turns out that the linker has started including the last modified time stamp of the object files in the (debug?) data and that time stamp data is included in the computed UUID "hash". So even if the rest of the data is the same between two builds, the build time (or, more accurately, the time when the object file gets written to the file system) now affects the UUID and therefore the data of the resulting .dylib files.
> 
> It seems (unconfirmed) like this may be an artifact of Xcode 15 using a new linker ("ld-prime") which may or may not be why the behavior has changed.
> 
> After spending even more time trying to understand what to do about it I noticed this in the ld man page:
> 
>      -reproducible
>              By default output content will be deterministic, but small changes in input files such as a compilation time might affect certain data structures in the linked binary. This option instructs ld to create a reproducible output binary by ignoring certain input properties or using alternative algorithms.
> 
> And, adding that flag (-Wl,-reproducible to clang) does indeed seem to solve the issue.
> 
> Testing:
> 
> * Manual verification with both Xcode14.3.1 and Xcode 15.4
> * tier1,builds-tier[2-5]

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23949#pullrequestreview-2670900587

From erik.joelsson at oracle.com  Mon Mar 10 13:41:58 2025
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Mar 2025 06:41:58 -0700
Subject: LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug
 symbols
In-Reply-To: <AM9PR02MB6770E7A120A769AAC04830FC93D62@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770E7A120A769AAC04830FC93D62@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <c5cd2d9b-9c82-4339-b322-0a86d7a32db6@oracle.com>

On 3/10/25 5:02 AM, Baesken, Matthias wrote:
>
> Hello, while looking at the JDK native lib optimization levels, I 
> noticed this special setting :
>
> make/modules/java.management/Lib.gmk
>
> ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
>
> LIBMANAGEMENT_OPTIMIZATION := LOW
>
> endif
>
> Why is it there ?
>
I've traced this back to [1]. In that change they lowered the 
optimization level to that of fastdebug for the libraries that had full 
debug symbols configured, at least for Linux. See code here [2]. The 
only explanation I can give is that they tried to be very conservative 
with the debug symbols change.

> I removed it ?in out internal tests and saw no issues.
>
> Do we still need it these days ? Was it maybe done for very old? gcc 
> versions ?
>
I very much doubt it's needed, but it does mean that this lib has been 
compiled at "LOW" for most, if not all, relevant builds of OpenJDK since 
then.

/Erik

[1] https://bugs.openjdk.org/browse/JDK-7071907
[2] 
https://github.com/openjdk/jdk7u/blob/6f892a5354bd5063418d74e32ded9653d24a768d/jdk/make/common/Defs-linux.gmk#L286
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250310/ae63523d/attachment-0001.htm>

From magnus.ihse.bursie at oracle.com  Mon Mar 10 13:42:37 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 14:42:37 +0100
Subject: LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug
 symbols
In-Reply-To: <AM9PR02MB6770E7A120A769AAC04830FC93D62@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770E7A120A769AAC04830FC93D62@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <1d2e83d3-80d7-4f38-a225-3cc80716a231@oracle.com>

On 2025-03-10 13:02, Baesken, Matthias wrote:

> Hello, while looking at the JDK native lib optimization levels, I 
> noticed this special setting :
>
> make/modules/java.management/Lib.gmk
>
> ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
>
> LIBMANAGEMENT_OPTIMIZATION := LOW
>
> endif
>
> Why is it there ?
>
> I removed it ?in out internal tests and saw no issues.
>
> Do we still need it these days ? Was it maybe done for very old? gcc 
> versions ?
>
That's a good question. As I've stated over and over again, I believe 
the overwhelming majority of the optimization flags are there for no 
good reason; at least for no reason that can be assumed to apply today.

In this particular case I did some git archaeology. It goes way back to 
JDK-8054834: Modular Source Code, the jigsaw reshuffling in 2014, and I 
did not manage to trace it roots from before that.

/Magnus

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

From ihse at openjdk.org  Mon Mar 10 13:48:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 13:48:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
 <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>
Message-ID: <g2XMt1vhpaPef9D_78B-x4Rn-hOQeSrBgyK2LJnTo2w=.5d1450d9-8fa0-4cbc-ade5-1a02e20a0250@github.com>

On Thu, 6 Mar 2025 13:27:15 GMT, snake66 <duke at openjdk.org> wrote:

>> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.
>> 
>> Needs build team approval before integrating.
>
>> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.
> 
> I noticed there were a few places that used `-pthread` by default. I left these alone in this PR.

@snake66 To integrate this, you need to give the command `/integrate` as a comment. Then I (or someone else) with committer permissions can sponsor the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2710652078

From matthias.baesken at sap.com  Mon Mar 10 13:49:26 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 10 Mar 2025 13:49:26 +0000
Subject: LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug
 symbols
In-Reply-To: <c5cd2d9b-9c82-4339-b322-0a86d7a32db6@oracle.com>
References: <AM9PR02MB6770E7A120A769AAC04830FC93D62@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <c5cd2d9b-9c82-4339-b322-0a86d7a32db6@oracle.com>
Message-ID: <AM9PR02MB6770DF2B311EBC4D4057A6E793D62@AM9PR02MB6770.eurprd02.prod.outlook.com>



  *   I very much doubt it's needed, but it does mean that this lib has been compiled at "LOW" for most, if not all, relevant builds of OpenJDK since then.

If I create a PR removing this special handling, could you please test it in your CI  to be sure that nothing bad happens ?
Best regards, Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250310/a99e11cc/attachment-0001.htm>

From ihse at openjdk.org  Mon Mar 10 13:52:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 13:52:56 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]
In-Reply-To: <3jbKFXHYH2mgyYOQjn2rfGm0IpIwH377DuDrZAY4X7w=.8d0767f3-7190-4396-824a-d55e6a61f479@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <cvZUOyaUr9G-miDbePX6Tmsum4Y5KMNjpTLKaL1W0Rc=.2096adec-dde0-4936-b18e-2090385b4349@github.com>
 <HcpND1YQVUVwQSHAkJtm0v0zNwDZ7nRhLXW6Z3r0hQk=.b360c659-4103-4280-80dc-b11d2f81f7bb@github.com>
 <ZE8xCvaV43R1NwFC043lKBgz4eOE-2ayAfYPWULRIFY=.aa2c7cc9-dc4e-47a2-973e-a330e0dddee8@github.com>
 <cTRgAAA0B5QD80WXj4zUi1BqGX7aPtkvRVXMN_BdQ-Y=.b377ddb4-cd40-4480-9237-c68f0cc56b39@github.com>
 <E3y7XfCv2LH1q7N2zj9ttzU8DinlQZ5sGmblzIGh7OY=.c3f5e69c-5be5-410e-88fd-cb14ed59984f@github.com>
 <3jbKFXHYH2mgyYOQjn2rfGm0IpIwH377DuDrZAY4X7w=.8d0767f3-7190-4396-824a-d55e6a61f479@github.com>
Message-ID: <dv_8CzmQRG5dyl-gIp-VTzAbmletcq7O5xYEXjGgHzw=.4243b7c3-e2cf-46a4-b140-3e0b3ba226a5@github.com>

On Mon, 10 Mar 2025 09:46:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The `--enable-deprecated-ports` is still there. All that is removed is an if statement and a print line. I know the make syntax can seem intimidating, but just ask me or any other build team member if you need help to recreate such a thing. It is not like it is a complicated algorithm that can be written in many ways. This is just make's equivalant of:
>> 
>> 
>> if (some_condition) {
>>   println("whatever");
>> }
>> 
>> 
>> To me this is just utter nonsense to keep that commented out.
>
> "Utter nonsense" might be a bit harsh. We do code samples around OpenJDK all the time to leave breadcrumbs for future use. As I said, I don't mind removing it, done so in new commit.

Yes, you are right. That did not sound good. I apologize. (And thanks for removing it!)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1987327814

From magnus.ihse.bursie at oracle.com  Mon Mar 10 14:08:53 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 15:08:53 +0100
Subject: LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug
 symbols
In-Reply-To: <AM9PR02MB6770DF2B311EBC4D4057A6E793D62@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770E7A120A769AAC04830FC93D62@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <c5cd2d9b-9c82-4339-b322-0a86d7a32db6@oracle.com>
 <AM9PR02MB6770DF2B311EBC4D4057A6E793D62@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <8fa98a2a-d02e-4fb0-a4af-71665ef6a52c@oracle.com>

On 2025-03-10 14:49, Baesken, Matthias wrote:

>   * I very much doubt it's needed, but it does mean that this lib has
>     been compiled at "LOW" for most, if not all, relevant builds of
>     OpenJDK since then.
>
> **
>
> If I create a PR removing this special handling, could you please test 
> it in your CI? to be sure that nothing bad happens ?
>
Sure.

/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250310/971d4cb2/attachment.htm>

From mbaesken at openjdk.org  Mon Mar 10 15:44:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 10 Mar 2025 15:44:19 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization
 settings
Message-ID: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>

On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

Commit messages:
 - JDK-8351542

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

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

From mbaesken at openjdk.org  Mon Mar 10 15:44:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 10 Mar 2025 15:44:19 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <uNpVp2VwO_3iyoMVRZJVGIgF1iep5lVA0VpUbiw7uIk=.d889dace-b61d-4068-90a6-6d1e9a1af0f0@github.com>

On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

While at it I also cleaned up some unused variable issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2711018344

From duke at openjdk.org  Mon Mar 10 15:49:55 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Mar 2025 15:49:55 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <WeHasZlBKvJdQ7MR4Y_CQiTzB7LCmrEvchELsF61MWU=.cc92b7d3-86ff-4f38-bddc-de7b7f62d74e@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

@snake66 
Your change (at version 469997239f26f59cd47df19fb9e836b883687487) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2711042802

From mikael at openjdk.org  Mon Mar 10 16:34:01 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 10 Mar 2025 16:34:01 GMT
Subject: RFR: 8351440: Link with -reproducible on macOS
In-Reply-To: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>
References: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>
Message-ID: <-oM28zHPAbcyBdq_BOkIfj4rXs8tckUqQD6Vto-wdbU=.6b9a75b3-db1b-4468-a689-73b94fb87f04@github.com>

On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> Recent versions of Xcode, most likely starting with Xcode 15, do not produce deterministic binaries/libraries out of the box. In particular, the UUID data in the LC_UUID load command is not stable.
> 
> After spending some significant time trying to understand why, it turns out that the linker has started including the last modified time stamp of the object files in the (debug?) data and that time stamp data is included in the computed UUID "hash". So even if the rest of the data is the same between two builds, the build time (or, more accurately, the time when the object file gets written to the file system) now affects the UUID and therefore the data of the resulting .dylib files.
> 
> It seems (unconfirmed) like this may be an artifact of Xcode 15 using a new linker ("ld-prime") which may or may not be why the behavior has changed.
> 
> After spending even more time trying to understand what to do about it I noticed this in the ld man page:
> 
>      -reproducible
>              By default output content will be deterministic, but small changes in input files such as a compilation time might affect certain data structures in the linked binary. This option instructs ld to create a reproducible output binary by ignoring certain input properties or using alternative algorithms.
> 
> And, adding that flag (-Wl,-reproducible to clang) does indeed seem to solve the issue.
> 
> Testing:
> 
> * Manual verification with both Xcode14.3.1 and Xcode 15.4
> * tier1,builds-tier[2-5]

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23949#issuecomment-2711171142

From mikael at openjdk.org  Mon Mar 10 16:34:01 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 10 Mar 2025 16:34:01 GMT
Subject: Integrated: 8351440: Link with -reproducible on macOS
In-Reply-To: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>
References: <TJfkyPJ3wvGvZyz04vyfzUQlntwXx048HJbDTStVxF4=.a21a8d38-62c3-4803-8179-e20d6c11ec64@github.com>
Message-ID: <nfbDHcMJDpu6zzhZXBESCyFHSjW_dEOUfgaNSA6lCO8=.f8fec193-2688-4102-ac2d-b86030d783d1@github.com>

On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> Recent versions of Xcode, most likely starting with Xcode 15, do not produce deterministic binaries/libraries out of the box. In particular, the UUID data in the LC_UUID load command is not stable.
> 
> After spending some significant time trying to understand why, it turns out that the linker has started including the last modified time stamp of the object files in the (debug?) data and that time stamp data is included in the computed UUID "hash". So even if the rest of the data is the same between two builds, the build time (or, more accurately, the time when the object file gets written to the file system) now affects the UUID and therefore the data of the resulting .dylib files.
> 
> It seems (unconfirmed) like this may be an artifact of Xcode 15 using a new linker ("ld-prime") which may or may not be why the behavior has changed.
> 
> After spending even more time trying to understand what to do about it I noticed this in the ld man page:
> 
>      -reproducible
>              By default output content will be deterministic, but small changes in input files such as a compilation time might affect certain data structures in the linked binary. This option instructs ld to create a reproducible output binary by ignoring certain input properties or using alternative algorithms.
> 
> And, adding that flag (-Wl,-reproducible to clang) does indeed seem to solve the issue.
> 
> Testing:
> 
> * Manual verification with both Xcode14.3.1 and Xcode 15.4
> * tier1,builds-tier[2-5]

This pull request has now been integrated.

Changeset: 8450ae90
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8450ae902ee012b6447015b24369eee85c091ec5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8351440: Link with -reproducible on macOS

Reviewed-by: erikj, ihse

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

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

From erikj at openjdk.org  Mon Mar 10 17:34:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 17:34:54 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>

On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

make/modules/java.management/Lib.gmk line 33:

> 31: ## Build libmanagement
> 32: ################################################################################
> 33: 

Why remove the comment header. This pattern is used throughout the `make/modules/*/Lib.gmk` files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1987739169

From honkar at openjdk.org  Mon Mar 10 17:51:15 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 10 Mar 2025 17:51:15 GMT
Subject: Integrated: JDK-8348597 : Update HarfBuzz to 10.4.0
In-Reply-To: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
References: <yvZfstBsKWvojD2-93EETB1S1v9S6j4MWCCJ5FzWfgo=.b0e89c80-7828-4bf8-a85c-58f992427de4@github.com>
Message-ID: <aRptPe17MqJarqsrU-5nArp9AU4MipSr3UbWsXqSiu4=.bbafc100-e23e-42b7-85bf-4a51dd1c33f8@github.com>

On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Harfbuzz upgraded to v10.4.0
> 
> File changes -
> 
> **Newly added files**
> 
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh 
> libharfbuzz/hb-ot-var-varc-table.hh 
> libharfbuzz/hb-subset-instancer-iup.hh  
> libharfbuzz/hb-subset-serialize.h
> 
> 
> **Deleted**
> 
> libharfbuzz/OT/glyf/VarCompositeGlyph.hh
> libharfbuzz/OT/glyf/coord-setter.hh
> 
> 
> **Modified: 182 existing files modified**
> 
> To prevent build failures due to dangling pointer (on linux) it has been added to HARFBUZZ_DISABLED_WARNINGS_gcc in [ClientLibraries.gmk](https://github.com/openjdk/jdk/pull/23910/files#diff-cd8423c7b5d9fc65d6553ebfd4c3721218c74f9bdb6a1039cc4e6fee8267cd13)

This pull request has now been integrated.

Changeset: dbdbbd47
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbdbbd473061d7e8077ed07ccc6b03065a8c2ffc
Stats:     18558 lines in 193 files changed: 10013 ins; 2990 del; 5555 mod

8348597: Update HarfBuzz to 10.4.0

Reviewed-by: erikj, prr

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

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

From jiangli at openjdk.org  Mon Mar 10 18:28:44 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Mar 2025 18:28:44 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk [v2]
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <nqwH0XTC-5O02wDrU5mxU-vTVhcZi54eBemGVdzjdqA=.75d51841-bb9b-47ae-a5ad-5a9d7afe4a23@github.com>

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:

 - Address magicus' feedback, set `ONLY_EXPORTED := true` for LIBJSIG.
 - Revert make/StaticLibs.gmk.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23924/files
  - new: https://git.openjdk.org/jdk/pull/23924/files/9e1aac2e..9419b7f1

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

  Stats: 8 lines in 2 files changed: 1 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23924/head:pull/23924

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

From jiangli at openjdk.org  Mon Mar 10 18:38:53 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Mar 2025 18:38:53 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <qrKql-eXWcuqGXg57SMHLgW4c6fu62bWr4-GCig9VPU=.aae9bd61-0ee6-4950-894b-7e8aeccf67ac@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <p6S-uNlOnLC9lqyJ4LhelYM0tjAu9wc3Xan2ULf9vPE=.05406ef1-8313-4cf5-ac46-3281edadbb82@github.com>
 <GC06yaeFbz0HY6-P4IH2qMT99jlUBAkvCoiV8lOzbx4=.0d4f63f6-c64c-4734-8aa6-9f8e041021f3@github.com>
 <qrKql-eXWcuqGXg57SMHLgW4c6fu62bWr4-GCig9VPU=.aae9bd61-0ee6-4950-894b-7e8aeccf67ac@github.com>
Message-ID: <GvfH7nEnDBS0MYzP5pml8_ziPCYia54xrsWTgfk2QOw=.f1707135-bff0-48f7-96e8-fb28a7282f9e@github.com>

On Fri, 7 Mar 2025 09:22:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>>> It seems we agree that we need, at some point, to have a high-level discussion on if libjsig should be supported on static builds, and if so, how it should be implemented. We also agree that having signal chaining enabled by default on our static JDK builds are incorrect.
>> 
>> Thumbs up.
>> 
>>> 
>>> However, I suggest we chose a simple path, were we utilize the framework for not building a static library that we do not use (this is already done for several libraries that are not included in the static JDK image), while you suggest we keep compiling it, even if we do not include it and test it.
>>> 
>>> I don't get the point of this. If we don't include it, and don't test it, then surely it would be better to not even build it now?
>> 
>> We have no current usages of libjsig in our current hermetic Java testing and prototype development work. So I don't have related concerns if don't produce a `libjsig.a` in the `static-libs` for the short term. Let's check with @dougxc and others from GraalVM side to make sure that they are okay with removing `libjsig.a` from the static libs bundle, before making any changes.
>
>> Let's check with @dougxc and others from GraalVM side
> 
> @wirthi or someone from the Native Image team will comment on this. Thanks for the heads up.

> > Let's check with @dougxc and others from GraalVM side to make sure that they are okay with removing libjsig.a from the static libs bundle, before making any changes.
> 
> Hi @jianglizhou,
> 
> Native image has no use for `libjsig.a` and we are fine if it is not part of static libs bundle.

Thanks for the feedback!

While making the change suggested by @magicus , I realize it `libjsig.a` is still included in the static libs bundle (at least not affect by the current change). It only exclude `libjsig.a` for `java.base` module-included-libs.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2711490133

From jiangli at openjdk.org  Mon Mar 10 18:43:04 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Mar 2025 18:43:04 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <Cd4HwT3pkU_8EsRHOszo9birQoXmCWbEhqAo1kPeCRw=.28bcd601-1d63-499c-8c83-136cef08fb77@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <Cd4HwT3pkU_8EsRHOszo9birQoXmCWbEhqAo1kPeCRw=.28bcd601-1d63-499c-8c83-136cef08fb77@github.com>
Message-ID: <lvfroJ1jRmxbX2FPEYWw1Gpk4w2jifXOBZQ_F6SsF1E=.d7e50476-db7a-4ab3-997b-34c1faa235a7@github.com>

On Mon, 10 Mar 2025 11:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With that confirmation, I think we should go on with the `ONLY_EXPORTED` solution instead.

Done. I also reverted StaticLibs.gmk change.

@caoman @tstuefe, please see if the updated change still looks okay to you.

> 
> If needed, we can revisit this in the future, to discuss how we should handle an optional library like libjsig. But that requires a complete solution througout the jmod/jlink pipeline to be meaningful.

Let's follow up with https://bugs.openjdk.org/browse/JDK-8351367.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2711500756

From mbaesken at openjdk.org  Mon Mar 10 18:54:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 10 Mar 2025 18:54:55 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings
In-Reply-To: <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>
Message-ID: <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com>

On Mon, 10 Mar 2025 17:32:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> make/modules/java.management/Lib.gmk line 33:
> 
>> 31: ## Build libmanagement
>> 32: ################################################################################
>> 33: 
> 
> Why remove the comment header. This pattern is used throughout the `make/modules/*/Lib.gmk` files.

My motivation was that the comment brings not much value because it just states the obvious. But if you like I can bring back the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1987847982

From bpb at openjdk.org  Mon Mar 10 22:23:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Mar 2025 22:23:04 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v11]
In-Reply-To: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
Message-ID: <0gRIhH2kkir2ojZFQ_JwXoo5K6TQ_6jM1jS_9kkzgU8=.2cd33484-171a-4443-834b-76ddd45b6b72@github.com>

On Thu, 5 Dec 2024 18:44:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 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 11 commits:
> 
>  - Merge
>  - Merge
>  - Merge
>  - 8337143: Minor makefile tweak
>  - 8337143: Clean up to address reviewer comments
>  - Merge
>  - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>  - Merge
>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/bedb68ab...2cb82267

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2711976367

From mikael at openjdk.org  Mon Mar 10 23:43:02 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 10 Mar 2025 23:43:02 GMT
Subject: RFR: 8351606: Use build_platform for graphviz dependency
Message-ID: <iSxNHuVc0P1MH6NZRVME6LiFiUy_xwwEMPhNGqT5V9o=.c3c5957e-1af9-4208-af5d-0cdfc875977f@github.com>

Background (from JBS):

graphviz is run during the build, and needs the build_platform variant rather than target_platform.

Testing:

tier1,builds-tier[2-5]

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

Commit messages:
 - 8351606: Use build_platform for graphviz dependency

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

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

From jlu at openjdk.org  Tue Mar 11 00:37:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Mar 2025 00:37:56 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <dFKNY64YaNuM4dyOdANWxnWFoeMEtfxl9Hm1mT5LM9E=.609167ac-4f2b-46a6-acee-a87b3d0264f7@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

Skimmed some tricky values and the conversions looked correct to me.
Since it was tested that the values are the same before and after, this change looks good to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22774#pullrequestreview-2672454949

From jlu at openjdk.org  Tue Mar 11 00:37:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Mar 2025 00:37:57 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v4]
In-Reply-To: <z291o0LyFlrFzcn_4SiqlLPiFaY56KCQ8rjEbQXaqzY=.e6d69344-1bd9-47a0-840e-87bcfda710ab@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
 <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
 <z291o0LyFlrFzcn_4SiqlLPiFaY56KCQ8rjEbQXaqzY=.e6d69344-1bd9-47a0-840e-87bcfda710ab@github.com>
Message-ID: <Xht5uew8BRiPQ24x2llPx98CwaT2R8HRdbLk1iXkZRo=.fd3f725b-89ff-4062-a594-b8118dfbef69@github.com>

On Mon, 10 Mar 2025 14:33:14 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 40:
>> 
>>> 38: If.keystore.is.not.password.protected.then.storepass.and.keypass.must.not.be.specified=Wenn der Keystore nicht kennwortgesch?tzt ist, d?rfen -storepass und -keypass nicht angegeben werden
>>> 39: Usage.jarsigner.options.jar.file.alias=Verwendung: jarsigner [options] jar-file alias
>>> 40: .jarsigner.verify.options.jar.file.alias.=\u0020      jarsigner -verify [options] jar-file [alias...]
>> 
>> We have generally kept `\u0020` in these properties files for the purpose of making it clear that trailing white space in a value is intentional. Can we convert these non trailing `\u0020` to just ` `?
>
> In properties files the whitespaces after `=` get trimmed when compiled, so when we replace `\u0020` with ` ` we get an incorrect string.

Ah, you're right, I am used to seeing those cases starting with `` to preserve the leading white space. Since it's just a stylistic choice, this seems fine then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1988192291

From mbaesken at openjdk.org  Tue Mar 11 09:04:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 09:04:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

  Bring back comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23966/files
  - new: https://git.openjdk.org/jdk/pull/23966/files/e6b748d4..fbe7f56e

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

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

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

From mbaesken at openjdk.org  Tue Mar 11 09:10:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 09:10:03 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>
 <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com>
Message-ID: <a7eQ1CiTpioOaFczPAfZqVMIyi48xDiNIBBqMYWhpPE=.11a7d94b-4ee6-4bc2-8285-957349a385cf@github.com>

On Mon, 10 Mar 2025 18:51:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> make/modules/java.management/Lib.gmk line 33:
>> 
>>> 31: ## Build libmanagement
>>> 32: ################################################################################
>>> 33: 
>> 
>> Why remove the comment header. This pattern is used throughout the `make/modules/*/Lib.gmk` files.
>
> My motivation was that the comment brings not much value because it just states the obvious. But if you like I can bring back the comment.

I brought back the comment, maybe it is better to keep it because of consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1988749705

From duke at openjdk.org  Tue Mar 11 09:12:45 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Tue, 11 Mar 2025 09:12:45 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
Message-ID: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>

> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.

David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:

  make editorconfig hotspot specific

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23693/files
  - new: https://git.openjdk.org/jdk/pull/23693/files/349997a8..c0e5ed47

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

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

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

From duke at openjdk.org  Tue Mar 11 09:15:57 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Tue, 11 Mar 2025 09:15:57 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
Message-ID: <MoJJT8f4pzkDQ4ZGowNNKK3LRpbgY4f7IA47y7I5t8M=.30dcc20c-ee96-4d94-a7dc-788c9bb26d21@github.com>

On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make editorconfig hotspot specific

I see. I didn't understand that the hotspot style guide is only for the hotspot part before.. seems obvious now :)

I like @erikj79 idea and have adapted the PR to this. It now defines `trim_trailing_whitespace` globally and indentation of 2 spaces for c/c++ hotspot code only.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2713264565

From kevinw at openjdk.org  Tue Mar 11 11:56:59 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Mar 2025 11:56:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
Message-ID: <c3fKGNxfAp0jBX_auVhkQdbgm-uUHEt2axXIL5NmGg0=.2146cc85-8fc7-4fda-8104-b137df5b5cbe@github.com>

On Tue, 11 Mar 2025 09:04:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back comment

src/java.management/share/native/libmanagement/VMManagementImpl.c line 63:

> 61: {
> 62:     jmmOptionalSupport mos;
> 63:     jmm_interface->GetOptionalSupport(env, &mos);

Is it worth making any change here?

We currently ignore the return value from GetOptionalSupport, and no doubt have done for years.
So is the fix to just not record the return value, or should we check it?

Making a change to not capture the return value looks like a statement that it should never be checked.  Even if GetOptionalSupport "can't" really fail with the current implementation, that doesn't seem like the right hint to leave.

Other usage in Java_com_sun_management_internal_DiagnosticCommandImpl_getDiagnosticCommandInfo
also does:
 jint ret = jmm_interface_management_ext->GetOptionalSupport(env, &mos);
 
...and also doesn't check the return value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989081708

From kevinw at openjdk.org  Tue Mar 11 13:24:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Mar 2025 13:24:01 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
Message-ID: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>

On Tue, 11 Mar 2025 09:04:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back comment

make/modules/java.management/Lib.gmk line 35:

> 33: 
> 34: LIBMANAGEMENT_OPTIMIZATION := HIGH
> 35: ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)

On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)`
..are we saying this is redundant?

It reads like Linux builds with LOW, and this change will change that to HIGH ?

I tested existing build and see -O2 in Linux fastdebug and release builds.  So this ifeq wasn't doing anything?

Windows fastdebug and release I just checked and saw -O1, I'm not sure why that is.

We do the same thing in make/modules/jdk.management/Lib.gmk so both these management locations should probably be treated the same.

(The same comparison is in make/modules/java.base/lib/CoreLibraries.gmk affecting LIBVERIFY_OPTIMIZATION, but no need to expand this change beyond the management area.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989256782

From mbaesken at openjdk.org  Tue Mar 11 13:39:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 13:39:00 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <c3fKGNxfAp0jBX_auVhkQdbgm-uUHEt2axXIL5NmGg0=.2146cc85-8fc7-4fda-8104-b137df5b5cbe@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <c3fKGNxfAp0jBX_auVhkQdbgm-uUHEt2axXIL5NmGg0=.2146cc85-8fc7-4fda-8104-b137df5b5cbe@github.com>
Message-ID: <3B8pMV5sb2cg79JQ1D5Elg4q_FpVpjU3ccyA8WJ8mcg=.6379566a-697c-4af9-85e2-8252f01cae3b@github.com>

On Tue, 11 Mar 2025 11:54:29 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Is it worth making any change here?

This was needed because I removed
DISABLED_WARNINGS_gcc_VMManagementImpl.c
while changing the makefile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989296776

From mbaesken at openjdk.org  Tue Mar 11 13:50:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 13:50:08 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
Message-ID: <rVIvHpWuYSQ3UoY9SeoXxIXGs6rGrbXv1Ml3mBkDaco=.f434dc99-6100-49c3-b389-f7093994b754@github.com>

On Tue, 11 Mar 2025 13:18:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Windows fastdebug and release I just checked and saw -O1, I'm not sure why that is.

The change touches only Linux so Windows stays as it is.

> We do the same thing in make/modules/jdk.management/Lib.gmk so both these management locations should probably be treated the same.

I look into this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989318978

From mbaesken at openjdk.org  Tue Mar 11 13:59:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 13:59:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <3B8pMV5sb2cg79JQ1D5Elg4q_FpVpjU3ccyA8WJ8mcg=.6379566a-697c-4af9-85e2-8252f01cae3b@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <c3fKGNxfAp0jBX_auVhkQdbgm-uUHEt2axXIL5NmGg0=.2146cc85-8fc7-4fda-8104-b137df5b5cbe@github.com>
 <3B8pMV5sb2cg79JQ1D5Elg4q_FpVpjU3ccyA8WJ8mcg=.6379566a-697c-4af9-85e2-8252f01cae3b@github.com>
Message-ID: <jUxe9o-rAaRmC1ezkisP7KeVhFrvHcscySaatF4C-WI=.1620603b-679a-4f0e-a3e8-c9517e92276c@github.com>

On Tue, 11 Mar 2025 13:36:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.management/share/native/libmanagement/VMManagementImpl.c line 63:
>> 
>>> 61: {
>>> 62:     jmmOptionalSupport mos;
>>> 63:     jmm_interface->GetOptionalSupport(env, &mos);
>> 
>> Is it worth making any change here?
>> 
>> We currently ignore the return value from GetOptionalSupport, and no doubt have done for years.
>> So is the fix to just not record the return value, or should we check it?
>> 
>> Making a change to not capture the return value looks like a statement that it should never be checked.  Even if GetOptionalSupport "can't" really fail with the current implementation, that doesn't seem like the right hint to leave.
>> 
>> Other usage in Java_com_sun_management_internal_DiagnosticCommandImpl_getDiagnosticCommandInfo
>> also does:
>>  jint ret = jmm_interface_management_ext->GetOptionalSupport(env, &mos);
>>  
>> ...and also doesn't check the return value.
>
>> Is it worth making any change here?
> 
> This was needed because I removed
> DISABLED_WARNINGS_gcc_VMManagementImpl.c
> while changing the makefile.

> Other usage in Java_com_sun_management_internal_DiagnosticCommandImpl_getDiagnosticCommandInfo also does: jint ret = jmm_interface_management_ext->GetOptionalSupport(env, &mos);
> 
> ...and also doesn't check the return value.

Seems this one needs the warning disabling because of the unused variable
DISABLED_WARNINGS_gcc_DiagnosticCommandImpl.c := unused-variable

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989338573

From mbaesken at openjdk.org  Tue Mar 11 14:14:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 14:14:16 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

  Adjust jdk.management/Lib.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23966/files
  - new: https://git.openjdk.org/jdk/pull/23966/files/fbe7f56e..2aa878e8

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

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

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

From kevinw at openjdk.org  Tue Mar 11 15:08:05 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Mar 2025 15:08:05 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
Message-ID: <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>

On Tue, 11 Mar 2025 14:14:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jdk.management/Lib.gmk

Hi,  I wasn't saying this is wrong, but that the change should say how it makes things better.  The issues says there are some things most likely not needed.  We should be a bit clearer than that, like:


The removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)`
Was this always redundant, and does removing it make no change to current build options?
If so, great, let's remove the useless makefile lines.


Remove a compiler directive to avoid unused var warnings, but change the code to make it imply a method has no return value when actually it returns a value: I think you could argue this either way, so I asked if it's really worthwhile.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2714681001

From duke at openjdk.org  Tue Mar 11 15:14:04 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 15:14:04 GMT
Subject: Integrated: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <k_Fo07yBcDWjQaVx8M-hu6RaoZ-DE1zHjXo4_PZblzw=.036d0461-a7e9-4b24-9cd3-ceb4da357745@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

This pull request has now been integrated.

Changeset: b957e5ed
Author:    Harald Eilertsen <haraldei at anduin.net>
URL:       https://git.openjdk.org/jdk/commit/b957e5ed1a8b77e01aad1bb574e4914131cdbfa6
Stats:     660 lines in 9 files changed: 9 ins; 0 del; 651 mod

8351322: Parameterize link option for pthreads

Reviewed-by: erikj, ihse, dholmes

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

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

From mbaesken at openjdk.org  Tue Mar 11 15:16:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 15:16:54 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
 <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
Message-ID: <TjVKTFhjwOMtoBJyUlmKbLFrC5J5zOvAlaQZWCEyPXY=.607061ac-ad4d-49bd-aa96-19db8f22edc1@github.com>

On Tue, 11 Mar 2025 15:04:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove a compiler directive to avoid unused var warnings, but change the code to make it imply a method has no return value when actually it returns a value: I think you could argue this either way, so I asked if it's really worthwhile.

I can move this into a separate PR, maybe it is indeed much better to separate in because it isn't related to the OPTIMIZATION settings.
Looking at the coding we might  get '-1' back
https://github.com/openjdk/jdk/blob/af9af7e90f7dab5adc7b89b76eb978d269e863de/src/hotspot/share/services/management.cpp#L491
so checking for the return code is probably a good idea (also at the other code location you mentioned).

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2714714952

From mbaesken at openjdk.org  Tue Mar 11 15:21:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 15:21:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
 <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
Message-ID: <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com>

On Tue, 11 Mar 2025 15:04:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Was this always redundant, and does removing it make no change to current build options?
> If so, great, let's remove the useless makefile lines.

There was a bit of discussion before in the thread https://mail.openjdk.org/pipermail/build-dev/2025-March/049419.html ' LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug symbols' and the outcome was that removing makes sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2714735126

From erikj at openjdk.org  Tue Mar 11 15:38:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 15:38:56 GMT
Subject: RFR: 8351606: Use build_platform for graphviz dependency
In-Reply-To: <iSxNHuVc0P1MH6NZRVME6LiFiUy_xwwEMPhNGqT5V9o=.c3c5957e-1af9-4208-af5d-0cdfc875977f@github.com>
References: <iSxNHuVc0P1MH6NZRVME6LiFiUy_xwwEMPhNGqT5V9o=.c3c5957e-1af9-4208-af5d-0cdfc875977f@github.com>
Message-ID: <-yHVILTohqAwtW9PVPJ2TEE3cIaKP3EsjRmYCnvWwtY=.0a5f897f-4e3a-40a3-86f3-e785c2ec9cee@github.com>

On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> graphviz is run during the build, and needs the build_platform variant rather than target_platform.
> 
> Testing:
> 
> tier1,builds-tier[2-5]

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23976#pullrequestreview-2675091265

From erikj at openjdk.org  Tue Mar 11 15:45:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 15:45:56 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <5irTdPcTdpBrzwzWUiAaZqHKbGINiONFtIYDLIguyws=.1f241454-7cae-4f45-9383-57953b37de8b@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

Build changes look good. Thanks for removing this special case in the build!

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22774#pullrequestreview-2675130279

From erikj at openjdk.org  Tue Mar 11 15:52:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 15:52:58 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
Message-ID: <s2Mnuv2lNoW9CjstZXMZSL0a3tV4ysfOghBPum-qSjc=.d0c838ee-5f09-42dd-83e7-f8c0c2294a06@github.com>

On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make editorconfig hotspot specific

Marked as reviewed by erikj (Reviewer).

I think this looks acceptable.

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

PR Review: https://git.openjdk.org/jdk/pull/23693#pullrequestreview-2675164206
PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2714845138

From erikj at openjdk.org  Tue Mar 11 16:02:00 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 16:02:00 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
 <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
 <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com>
Message-ID: <qtEFUk2gHw4Si5gOrkYU7UzWIMS0lD_FzqjPDVjq6r8=.cb445317-5d97-4f58-ae7b-e7b7c79a97bf@github.com>

On Tue, 11 Mar 2025 15:19:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Was this always redundant, and does removing it make no change to current build options?
> > If so, great, let's remove the useless makefile lines.
> 
> There was a bit of discussion before in the thread https://mail.openjdk.org/pipermail/build-dev/2025-March/049419.html ' LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug symbols' and the outcome was that removing makes sense.

My conclusion in that thread was that [JDK-7071907](https://bugs.openjdk.org/browse/JDK-7071907) introduced this (for a number of libraries). Before that change, these libraries were built with optimization HIGH, and after, because we (Oracle and I assume most other distributors) always build with debug symbols enabled, the optimization level for these libraries was de facto changed to LOW. This PR would revert that, so it does indeed change how the build behaves. There is at least some historic precedent for changing it this way, even if it was 13 years ago.

I think what Kevin is after is having this explanation made clear in the bug and PR description so that it's made clear what the change is and intends to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2714883676

From mikael at openjdk.org  Tue Mar 11 16:05:07 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 11 Mar 2025 16:05:07 GMT
Subject: RFR: 8351606: Use build_platform for graphviz dependency
In-Reply-To: <iSxNHuVc0P1MH6NZRVME6LiFiUy_xwwEMPhNGqT5V9o=.c3c5957e-1af9-4208-af5d-0cdfc875977f@github.com>
References: <iSxNHuVc0P1MH6NZRVME6LiFiUy_xwwEMPhNGqT5V9o=.c3c5957e-1af9-4208-af5d-0cdfc875977f@github.com>
Message-ID: <onoc1BrVw8oy7ffFE3ALUJ-A6Xdz4rXOa3yWswfRIXA=.055e409c-bbb7-440f-8ae2-f41ccc8ef3fb@github.com>

On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> graphviz is run during the build, and needs the build_platform variant rather than target_platform.
> 
> Testing:
> 
> tier1,builds-tier[2-5]

Thank you for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23976#issuecomment-2714889276

From mikael at openjdk.org  Tue Mar 11 16:05:08 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 11 Mar 2025 16:05:08 GMT
Subject: Integrated: 8351606: Use build_platform for graphviz dependency
In-Reply-To: <iSxNHuVc0P1MH6NZRVME6LiFiUy_xwwEMPhNGqT5V9o=.c3c5957e-1af9-4208-af5d-0cdfc875977f@github.com>
References: <iSxNHuVc0P1MH6NZRVME6LiFiUy_xwwEMPhNGqT5V9o=.c3c5957e-1af9-4208-af5d-0cdfc875977f@github.com>
Message-ID: <tCTHYbKUhe3Jq5HB2yRbJ_7hao1p9x9FQytILMw0qFs=.8bd8d0d0-71ac-4d98-9848-8752decf037f@github.com>

On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background (from JBS):
> 
> graphviz is run during the build, and needs the build_platform variant rather than target_platform.
> 
> Testing:
> 
> tier1,builds-tier[2-5]

This pull request has now been integrated.

Changeset: da2b4f07
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da2b4f0749dffc99fa42c7311fbc74231af273bd
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8351606: Use build_platform for graphviz dependency

Reviewed-by: erikj

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

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

From kevinw at openjdk.org  Tue Mar 11 18:40:03 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Mar 2025 18:40:03 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
Message-ID: <BAgwiarK__f12_Or-7x_sFNvmfzexOe080Ejr9hitWU=.5b43872e-9a20-4658-b5c1-896af581ee6a@github.com>

On Tue, 11 Mar 2025 14:14:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jdk.management/Lib.gmk

Yes - this might be a really good change, to move the optimization level up, but we need to be clear what is happening and why, in case it throws up some new issues.

Yes, I would agree with handling the unused variable changes separately.  If somebody finds a problem with the opt level, it can be reverted without other complications.

(and separately, maybe it's worth handling the return value of GetOptionalSupport, which in our implementation really can't be -1 unless you call it  wrongly, but strange things happen and things change 8-) )

I can do some tiers of CI testing to see if any odd issues pop up.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2715367338

From manc at openjdk.org  Tue Mar 11 18:55:54 2025
From: manc at openjdk.org (Man Cao)
Date: Tue, 11 Mar 2025 18:55:54 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk [v2]
In-Reply-To: <nqwH0XTC-5O02wDrU5mxU-vTVhcZi54eBemGVdzjdqA=.75d51841-bb9b-47ae-a5ad-5a9d7afe4a23@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <nqwH0XTC-5O02wDrU5mxU-vTVhcZi54eBemGVdzjdqA=.75d51841-bb9b-47ae-a5ad-5a9d7afe4a23@github.com>
Message-ID: <1xtq0lAHkDTiuHf10aKQsVeMAna7KULfQWUWsoiamZA=.755e8587-39d2-4db6-8f11-848f834580dc@github.com>

On Mon, 10 Mar 2025 18:28:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address magicus' feedback, set `ONLY_EXPORTED := true` for LIBJSIG.
>  - Revert make/StaticLibs.gmk.

Still LGTM. I recommend waiting for approval from @magicus as well.

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

Marked as reviewed by manc (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23924#pullrequestreview-2675782966

From jiangli at openjdk.org  Tue Mar 11 18:55:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Mar 2025 18:55:55 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <lvfroJ1jRmxbX2FPEYWw1Gpk4w2jifXOBZQ_F6SsF1E=.d7e50476-db7a-4ab3-997b-34c1faa235a7@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <Cd4HwT3pkU_8EsRHOszo9birQoXmCWbEhqAo1kPeCRw=.28bcd601-1d63-499c-8c83-136cef08fb77@github.com>
 <lvfroJ1jRmxbX2FPEYWw1Gpk4w2jifXOBZQ_F6SsF1E=.d7e50476-db7a-4ab3-997b-34c1faa235a7@github.com>
Message-ID: <Au6IodX6VoohwfKSxffwzSJRT4bWgrxbgfdISxp274M=.e2f9cda3-f578-4dd8-9b25-d9b1ff3ddaa5@github.com>

On Mon, 10 Mar 2025 18:39:46 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > With that confirmation, I think we should go on with the `ONLY_EXPORTED` solution instead.
> 
> Done. I also reverted StaticLibs.gmk change.
> 
> @caoman @tstuefe, please see if the updated change still looks okay to you.

I also tested with running `jlink` to create a custom JDK (dynamic regular). This change does not affect that. `libjsig.so` is still properly included in the jlink'ed output JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2715404720

From jiangli at openjdk.org  Tue Mar 11 19:12:59 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Mar 2025 19:12:59 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <Cd4HwT3pkU_8EsRHOszo9birQoXmCWbEhqAo1kPeCRw=.28bcd601-1d63-499c-8c83-136cef08fb77@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <Cd4HwT3pkU_8EsRHOszo9birQoXmCWbEhqAo1kPeCRw=.28bcd601-1d63-499c-8c83-136cef08fb77@github.com>
Message-ID: <iV2JLXop6FqjpZCcwOa4hujA2-nvoZT9qjvaFNUedRE=.00c0e4a3-0e60-48c8-ba5d-2f1c0d3b661c@github.com>

On Mon, 10 Mar 2025 11:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks
>
> With that confirmation, I think we should go on with the `ONLY_EXPORTED` solution instead. 
> 
> If needed, we can revisit this in the future, to discuss how we should handle an optional library like libjsig. But that requires a complete solution througout the jmod/jlink pipeline to be meaningful.

> Still LGTM. I recommend waiting for approval from @magicus as well.

Thanks @caoman! Yes, we should wait for @magicus.

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2715440185

From duke at openjdk.org  Tue Mar 11 19:29:06 2025
From: duke at openjdk.org (duke)
Date: Tue, 11 Mar 2025 19:29:06 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <joV_S3_Xkms97gK-ZPrW3mA3GyTTDTa0YsRUtuutZ8w=.5bad390d-c0bf-4dfc-9fbf-86c5d3b4882a@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

@artur-oracle 
Your change (at version 7d911bce09aa7ee1684a6f35cdb11e96167a53a3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22774#issuecomment-2715472109

From fthevene at redhat.com  Tue Mar 11 19:29:41 2025
From: fthevene at redhat.com (Frederic Thevenet)
Date: Tue, 11 Mar 2025 20:29:41 +0100
Subject: [Proposal] Add code signing on Windows to the JDK build system
In-Reply-To: <37182570-6ec8-47cc-8560-b3014f07df2c@oracle.com>
References: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com>
 <b85b8665-2d52-4aa6-ad70-94298cbf10f4@oracle.com>
 <79bc54ec-fd5d-4803-914d-01c64ef88a98@redhat.com>
 <1f1fd802-72e0-4b27-9a77-9d9ed913caf3@oracle.com>
 <37182570-6ec8-47cc-8560-b3014f07df2c@oracle.com>
Message-ID: <4e501adc-aed7-4c56-8157-155b87b732b4@redhat.com>

Hi Magnus,

As mentioned before, the core idea here is really just providing a hook 
for a script to be invoked after the native linker has been called.
So while thinking about making this more generic and not Windows 
specific, it struck me that it might in fact be desirable to also drop 
the "signing" notion from this altogether and instead consider it a way 
to extend to the build system by plugging in custom scripts? And maybe 
extend it with other strategically placed hooks?

Do you think this is a direction worth exploring further? Or that the 
original, more focused scope is preferable?

Thanks,
Frederic


On 07/03/2025 16:49, Magnus Ihse Bursie wrote:
> Hi Frederic,
>
> I think your proposal makes sense, and as Erik says, the patch is very 
> unobtrusive.
>
> I'm not at all sure if it is even possible, but if the signing logic 
> for macOS and Windows can be sort of unified and made more abstract, 
> that would certainly be a win.
>
> /Magnus
>
>
> On 2025-02-26 20:46, Erik Joelsson wrote:
>> On 2/26/25 10:40 AM, Frederic Thevenet wrote:
>>> Hi Erik,
>>>
>>> Thanks for your comments.
>>>
>>> As a matter of fact, we at Red Hat also face similar constraints 
>>> that prevent us from being able to sign the files on the machine 
>>> that build them (and I suspect this is quite common-place).
>>>
>>> My initial idea to accommodate that is to have the jdk build invoke 
>>> a user supplied script (via a --with configure argument) rather than 
>>> having it call signtool directly, so as to provide a way for 
>>> everyone to easily plug their specific configuration and logic (in 
>>> our case, the script uploads the file to sign to the signing machine 
>>> and download it once it is done, in a synchronous fashion).
>>>
>>> In effect, it's just a hook that is invoked after the native linker 
>>> has been called.
>>>
>>> I have created a PR[1] where you can see what I've done in details.
>>
>> That's a small and unintrusive solution. Our solution is a lot more 
>> involved as I figured I wanted to expose a set of top level "phase" 
>> targets for signing for each module, so that building libs or 
>> launchers can be done independently from signing (e.g. 
>> java.base-libs, java.base-launchers and java.base-sign). This 
>> necessitates a separate set of output directories for signed libs and 
>> signed launchers, where we first build like normal to the regular 
>> output dirs and then the sign target copies and signs binaries into 
>> the *-signed outputdirs, and when building jmods, we need to pick up 
>> the files from those *-signed directories. It's quite messy, so I've 
>> kept it all in our internal makefile extensions. I'm also questioning 
>> the usefulness of this flexibility given how much complexity it adds, 
>> so your proposal is probably preferred.
>>
>> That said, I'm wondering if we could make it a bit more generic and 
>> not define it as "windows" specific? Then perhaps bake in the macos 
>> signing logic into this as well. The default implementation could be 
>> using the native OS tools while there is a configure option to 
>> completely replace it.
>>
>> /Erik
>>
>>>
>>> Thanks,
>>> Frederic
>>>
>>> [1] https://github.com/openjdk/jdk/pull/23807
>>>
>>> On 26/02/2025 15:29, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> I think this is a reasonable idea and you are welcome to implement 
>>>> it. At Oracle we have been solving this using custom extension 
>>>> makefiles. That will unfortunately not change with this proposal as 
>>>> our signing process does not involve direct access to the native 
>>>> tools of the OS. Perhaps this implementation could be made 
>>>> plug-able enough so that we could leverage it, I'm not sure. What 
>>>> I'm trying to say is that we are not against this, but we are also 
>>>> not inclined to invest resources into it.
>>>>
>>>> /Erik
>>>>
>>>> On 2/26/25 12:52 AM, Frederic Thevenet wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to start a discussion about adding built-in support 
>>>>> for code signing native executable file and dynamic library on 
>>>>> Windows directly as part of the JDK build, in a similar fashion to 
>>>>> what already exists for macOS.
>>>>>
>>>>> Most, if not all vendors already ensure that every native 
>>>>> executable files and dynamic libraries that are part of the binary 
>>>>> builds of OpenJDK that they distribute to their customers for the 
>>>>> Windows platform are digitally signed using a set of Microsoft 
>>>>> APIs and tools called Authenticode[1].
>>>>>
>>>>> Since this is not a part of the existing JDK build system, 
>>>>> however, this means that each vendor has had to come up with their 
>>>>> own way to integrate the code signing step into their build pipeline.
>>>>> As the shape of the JDK binary deliverable evolved to accommodate 
>>>>> features like modules, signing binaries as an after-the-fact 
>>>>> process has gradually become more complicated and error prone.
>>>>>
>>>>> For instance, with the introduction of JEP 493 (Linking Run-Time 
>>>>> Images without JMODs)[2], adding a digital signature to files 
>>>>> after jlink runs as part of the build to create the JDK image when 
>>>>> the new '--generate-linkable-runtime' feature is enabled will 
>>>>> cause any subsequent uses of jlink from this image to fail with a 
>>>>> "Error:<xxxx> has been modified" error.
>>>>>
>>>>> The solution to that particular problem is to ensure that the 
>>>>> signature is applied before jlink generates the checksums it will 
>>>>> later use to detect , and I believe the best way to achieve that 
>>>>> is to integrate code signing as an option in the jdk build process.
>>>>>
>>>>> This would also offer vendors who decide to opt into using this 
>>>>> new feature to potentially simplify their overall build process.
>>>>> For instance, this could get rid of extra steps such as filtering 
>>>>> out dlls that are part of the bundle but were not built as part of 
>>>>> the jdk (e.g. the Microsoft C and C++ runtime redistributables), 
>>>>> or making sure that 'exe' and 'dll' files packaged in the .jmod 
>>>>> files are also signed.
>>>>>
>>>>> As a stated before a very similar option already exists for code 
>>>>> signing on the macOS platform, which further reinforce my thinking 
>>>>> that such a feature would make sense for Windows as well.
>>>>>
>>>>> I have drafted a prototype for this and would be happy to create 
>>>>> JBS issue and submit a PR to move this forward, provided there is 
>>>>> interest.
>>>>>
>>>>> Thanks,
>>>>> Frederic Thevenet (fthevenet)
>>>>>
>>>>> [1] 
>>>>> https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537359(v=vs.85)
>>>>> [2] https://openjdk.org/jeps/493
>>>>>
>>>>
>>>
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92


From duke at openjdk.org  Tue Mar 11 19:30:22 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 19:30:22 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
Message-ID: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>

Allows for future support for platforms that require different flags for libiconv support.

Sponsored-by: The FreeBSD Foundation

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

Commit messages:
 - 8351323: Parameterize libiconv compiler and linker flags

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

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

From erikj at openjdk.org  Tue Mar 11 19:37:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 19:37:58 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>

On Tue, 11 Mar 2025 19:22:34 GMT, snake66 <duke at openjdk.org> wrote:

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

I think this looks ok, but please wait for Magnus to have a look too.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23995#pullrequestreview-2675894294

From duke at openjdk.org  Tue Mar 11 19:48:58 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 19:48:58 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
Message-ID: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>

On Tue, 11 Mar 2025 19:35:45 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> I think this looks ok, but please wait for Magnus to have a look too.

@erikj79 Thanks for the review. I'll wait for Magnus as well, and for the tests to pass :)

One thing I was wondering about is that with this change I think it should be safe to just use `$(ICONV_CFLAGS)` etc when setting the main variable.

I.e. instead of:


      CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
          $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS), \
      CFLAGS_aix := $(ICONV_CFLAGS), \
      CFLAGS_macosx := $(ICONV_CFLAGS), \


We could just do:


      CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
          $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS) \
          $(ICONV_CFLAGS), \


The reason I kept it separate for now is that it used separate assignments for the LDFLAGS variable per platform.

However, it you consider it better to combine it into one platform neutral assignment, I can do that instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2715520647

From abarashev at openjdk.org  Tue Mar 11 20:10:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 11 Mar 2025 20:10:04 GMT
Subject: Integrated: 8345940: Migrate security-related resources from Java
 classes to properties files
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <FCtiyh0S_yfUYdLgDUGKtOQkoK0lNKLxRlzJbVtCgcQ=.7b72dbba-e11c-4717-a32d-8c1a75b19c42@github.com>

On Mon, 16 Dec 2024 22:03:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

This pull request has now been integrated.

Changeset: 9a494181
Author:    Artur Barashev <abarashev at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a49418138b93bc8ed8879be5c9b9b9c85ef47e1
Stats:     16201 lines in 83 files changed: 6064 ins; 10109 del; 28 mod

8345940: Migrate security-related resources from Java classes to properties files

Reviewed-by: jlu, weijun, erikj

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

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

From eirbjo at openjdk.org  Wed Mar 12 05:51:58 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 12 Mar 2025 05:51:58 GMT
Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2]
In-Reply-To: <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
References: <smlG1F-3z7kPJlknt6IHx0PKu06ouIvurmbC6AQhyZ4=.8fcaa90e-efa6-4c14-838c-6ecdd505e1a0@github.com>
 <AODEuJObduOXeH6FMeyNFVupyK_dJJLNHmZNQXP0wIU=.1c181935-7c6c-4f87-9e27-3a69afbdadc7@github.com>
Message-ID: <noUkc7x9v2KTtQcOwZz581F9XbtMYeEjKopDXCpA9Ik=.8101fe49-1867-4474-b14c-f792aff79e62@github.com>

On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>> 
>> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
>> 
>> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
>> 
>> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Drop commented out block from deprecations
>  - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone
>  - Generic 32-bit x86 configure error supercedes Windows 32-bit x86
>  - 8345169: Implement JEP 503: Remove the 32-bit x86 Port

> JEP 486 (Permanently Disable the Security Manager) updated the API and removed the ability to set a SecurityManager in a first big commit. [..]  There were 150+ follow on issues

Observation: These JEP 486 follow-on issues served as a nice way for non-experts to contribute with something useful and also to get acquainted with various parts of the OpenJDK code base. Most cleanups followed a predictable pattern, so the implementation work could be distributed also to people not intimately familiar with the particular area without too much risk.

Not sure how well this conveys to JEP 503, but I imagine something similar should be possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2716580939

From mbaesken at openjdk.org  Wed Mar 12 08:24:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 08:24:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <qtEFUk2gHw4Si5gOrkYU7UzWIMS0lD_FzqjPDVjq6r8=.cb445317-5d97-4f58-ae7b-e7b7c79a97bf@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
 <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
 <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com>
 <qtEFUk2gHw4Si5gOrkYU7UzWIMS0lD_FzqjPDVjq6r8=.cb445317-5d97-4f58-ae7b-e7b7c79a97bf@github.com>
Message-ID: <LBNwFffd5rbsjx3hRGRi7Ku6L7W2W_p8VpKL1vd5ah0=.503177fd-a862-4cc8-9b12-cf9816d4f23c@github.com>

On Tue, 11 Mar 2025 15:59:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think what Kevin is after is having this explanation made clear in the bug and PR description so that it's made clear what the change is and intends to do.

I changed the description in the JBS issue a bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2717019564

From mbaesken at openjdk.org  Wed Mar 12 11:18:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 11:18:15 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <F7izoURvgkTLmRlXq2z-G005YR_rOyzWSVXgxEi6bZw=.283a3a99-c3d2-4265-b2fc-7ab5cd257129@github.com>

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

  do not handle the unused variables stuff in this change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23966/files
  - new: https://git.openjdk.org/jdk/pull/23966/files/2aa878e8..979963a9

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

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

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

From ihse at openjdk.org  Wed Mar 12 11:18:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 11:18:15 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
Message-ID: <fQZaL5F5yG9kT1t-nvC8b3VA_u_k9Duy-vTQeEWLKTU=.678ad67b-f5ad-47ec-9c5a-7ba5355ed9a5@github.com>

On Tue, 11 Mar 2025 13:18:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do not handle the unused variables stuff in this change
>
> make/modules/java.management/Lib.gmk line 35:
> 
>> 33: 
>> 34: LIBMANAGEMENT_OPTIMIZATION := HIGH
>> 35: ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
> 
> On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)`
> ..are we saying this is redundant?
> 
> It reads like Linux builds with LOW, and this change will change that to HIGH ?
> 
> I tested existing build and see -O2 in Linux fastdebug and release builds.  So this ifeq wasn't doing anything?
> 
> Windows fastdebug and release I just checked and saw -O1, I'm not sure why that is.
> 
> We do the same thing in make/modules/jdk.management/Lib.gmk so both these management locations should probably be treated the same.
> 
> (The same comparison is in make/modules/java.base/lib/CoreLibraries.gmk affecting LIBVERIFY_OPTIMIZATION, but no need to expand this change beyond the management area.)

@kevinjwalls 
> On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)` ..are we saying this is redundant?
> 
> It reads like Linux builds with LOW, and this change will change that to HIGH ?

No, we are not saying it is redundant. Exactly as you say this PR will change the value from LOW to HIGH. The assumption is that this special case was created more than a decade ago, and no ill effect seems to arise when removing the exception, so it seems to be needed no more. 

This is part of Matthias ongoing effort to simplify and modernize the optimization levels of native libraries in the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991242742

From ihse at openjdk.org  Wed Mar 12 11:18:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 11:18:15 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <F7izoURvgkTLmRlXq2z-G005YR_rOyzWSVXgxEi6bZw=.283a3a99-c3d2-4265-b2fc-7ab5cd257129@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <F7izoURvgkTLmRlXq2z-G005YR_rOyzWSVXgxEi6bZw=.283a3a99-c3d2-4265-b2fc-7ab5cd257129@github.com>
Message-ID: <uOjWByBEQmtqflpbbXtTYAnTN19Mc_6MVxCwlH3lJh8=.020eadd6-4489-47d5-a67e-bdd5e815c6f4@github.com>

On Wed, 12 Mar 2025 11:15:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not handle the unused variables stuff in this change

src/java.management/share/native/libmanagement/VMManagementImpl.c line 41:

> 39:     jstring version_string = NULL;
> 40: 
> 41:     unsigned int major = ((unsigned int) jmm_version & 0x0FFF0000) >> 16;

Can you please revert this unrelated changes as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991245086

From ihse at openjdk.org  Wed Mar 12 11:18:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 11:18:15 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <a7eQ1CiTpioOaFczPAfZqVMIyi48xDiNIBBqMYWhpPE=.11a7d94b-4ee6-4bc2-8285-957349a385cf@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>
 <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com>
 <a7eQ1CiTpioOaFczPAfZqVMIyi48xDiNIBBqMYWhpPE=.11a7d94b-4ee6-4bc2-8285-957349a385cf@github.com>
Message-ID: <75SREzlDoYwqWP8IeEVKUH6x8ZXagK6nDUkULmBnid0=.eda00d2d-e721-44f9-b890-edad0fe3f5b7@github.com>

On Tue, 11 Mar 2025 09:07:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> My motivation was that the comment brings not much value because it just states the obvious. But if you like I can bring back the comment.
>
> I brought back the comment, maybe it is better to keep it because of consistency.

Thank you. I have introduced these headers everywhere to to create consistency and an easy way to search for where native libraries are compiled, so they are definitely useful even if that is not obvious from a single example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991238672

From kevinw at openjdk.org  Wed Mar 12 11:24:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Mar 2025 11:24:08 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <fQZaL5F5yG9kT1t-nvC8b3VA_u_k9Duy-vTQeEWLKTU=.678ad67b-f5ad-47ec-9c5a-7ba5355ed9a5@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
 <fQZaL5F5yG9kT1t-nvC8b3VA_u_k9Duy-vTQeEWLKTU=.678ad67b-f5ad-47ec-9c5a-7ba5355ed9a5@github.com>
Message-ID: <2_A1TGBk_QUchp1EvYXWZpLJ_JZRLGgFvZM5Ia91fjE=.295280a9-0f96-41aa-b8d9-b80ebc092813@github.com>

On Wed, 12 Mar 2025 11:13:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.management/Lib.gmk line 35:
>> 
>>> 33: 
>>> 34: LIBMANAGEMENT_OPTIMIZATION := HIGH
>>> 35: ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
>> 
>> On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)`
>> ..are we saying this is redundant?
>> 
>> It reads like Linux builds with LOW, and this change will change that to HIGH ?
>> 
>> I tested existing build and see -O2 in Linux fastdebug and release builds.  So this ifeq wasn't doing anything?
>> 
>> Windows fastdebug and release I just checked and saw -O1, I'm not sure why that is.
>> 
>> We do the same thing in make/modules/jdk.management/Lib.gmk so both these management locations should probably be treated the same.
>> 
>> (The same comparison is in make/modules/java.base/lib/CoreLibraries.gmk affecting LIBVERIFY_OPTIMIZATION, but no need to expand this change beyond the management area.)
>
> @kevinjwalls 
>> On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)` ..are we saying this is redundant?
>> 
>> It reads like Linux builds with LOW, and this change will change that to HIGH ?
> 
> No, we are not saying it is redundant. Exactly as you say this PR will change the value from LOW to HIGH. The assumption is that this special case was created more than a decade ago, and no ill effect seems to arise when removing the exception, so it seems to be needed no more. 
> 
> This is part of Matthias ongoing effort to simplify and modernize the optimization levels of native libraries in the JDK.

Thanks yes, I could not reconcile the "most likely not needed" statement with the implied "this will change the opt level", so the intent wasn't clear at first.  I think we're in sync now. 
 Agreed the opt level should be a good change!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991262315

From ihse at openjdk.org  Wed Mar 12 11:26:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 11:26:00 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk [v2]
In-Reply-To: <nqwH0XTC-5O02wDrU5mxU-vTVhcZi54eBemGVdzjdqA=.75d51841-bb9b-47ae-a5ad-5a9d7afe4a23@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <nqwH0XTC-5O02wDrU5mxU-vTVhcZi54eBemGVdzjdqA=.75d51841-bb9b-47ae-a5ad-5a9d7afe4a23@github.com>
Message-ID: <ib8Cy1gYhYNMb1LGK9xY-ZQ8UgMIGOikaHbbuqQ9w8s=.72c2dc4a-e6fd-4a3c-a500-f1041ea20f15@github.com>

On Mon, 10 Mar 2025 18:28:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address magicus' feedback, set `ONLY_EXPORTED := true` for LIBJSIG.
>  - Revert make/StaticLibs.gmk.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23924#pullrequestreview-2678066792

From ihse at openjdk.org  Wed Mar 12 12:14:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 12:14:52 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
Message-ID: <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>

On Tue, 11 Mar 2025 19:45:58 GMT, snake66 <duke at openjdk.org> wrote:

> We could just do:
> 
> ```
>       CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
>           $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS) \
>           $(ICONV_CFLAGS), \
> ```
> 
> The reason I kept it separate for now is that it used separate assignments for the LDFLAGS variable per platform.
> 
> However, it you consider it better to combine it into one platform neutral assignment, I can do that instead.

This form is much preferred -- if it is possible and correct. That is, if iconv is used on all platforms where it is available.

>From the diff in the PR, it looks like iconv is used exclusively on macOS and AIX. If so, you can change the definition of ICONV_CFLAG etc to be empty on all platforms except on macOS and AIX (and in the upcoming BSD port), and just add the ICONV variables directly as platform neutral. 

But for this to be a good idea, there need to be some sense that this is "futureproof", as in that there will likely never be a need for iconv on Linux, and that there is a reasonable assumption to think that if a JDK library needs iconv it will need it on all "iconv platforms", that is macOS, AIX and BSD. I don't know enough about the specifics of iconv to say this with certainty. Another way to phrase this is perhaps: "why don't we need iconv on linux?"

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717683240

From ihse at openjdk.org  Wed Mar 12 12:17:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 12:17:57 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
 <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
Message-ID: <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>

On Wed, 12 Mar 2025 12:12:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Another way to phrase this is perhaps: "why don't we need iconv on linux?"

I googled this and can answer it myself: because `iconv()` is built into glibc. So then I guess it makes sense to add ICONV variables globally, and define it as empty on linux (and windows), where it is not needed to be specified as a separate library.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717689442

From duke at openjdk.org  Wed Mar 12 12:26:53 2025
From: duke at openjdk.org (snake66)
Date: Wed, 12 Mar 2025 12:26:53 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
 <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
 <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>
Message-ID: <GFAItR-gpg2wTrUmZJKQhnQ8nGioIhnMbmVgMOxE5_8=.c4e320d5-86f1-46ce-b5c2-464a5a67cf33@github.com>

On Wed, 12 Mar 2025 12:15:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Another way to phrase this is perhaps: "why don't we need iconv on linux?"
> 
> I googled this and can answer it myself: because `iconv()` is built into glibc. 

Yes, that's what I came to as well. Sorry I didn't include that info in the original description. It seems to be even more complicated on some platforms, where there _is_ built in support for iconv (or a system supplied libiconv), but with limitations so that you may want to prefer the GNU libiconv in any case.

I think we should be able to configure these cases properly also with the proposed changes.

I'll update the PR as outlined in the previous comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717713872

From mbaesken at openjdk.org  Wed Mar 12 12:45:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 12:45:48 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

  move code back in VMManagementImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23966/files
  - new: https://git.openjdk.org/jdk/pull/23966/files/979963a9..d82bd2b6

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

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

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

From mbaesken at openjdk.org  Wed Mar 12 12:45:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 12:45:50 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <uOjWByBEQmtqflpbbXtTYAnTN19Mc_6MVxCwlH3lJh8=.020eadd6-4489-47d5-a67e-bdd5e815c6f4@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <F7izoURvgkTLmRlXq2z-G005YR_rOyzWSVXgxEi6bZw=.283a3a99-c3d2-4265-b2fc-7ab5cd257129@github.com>
 <uOjWByBEQmtqflpbbXtTYAnTN19Mc_6MVxCwlH3lJh8=.020eadd6-4489-47d5-a67e-bdd5e815c6f4@github.com>
Message-ID: <7htIj8fq8F1fm1ldEYSZ7qbjGUwmsJoxidI_2inw9FI=.48926cd9-79b4-4674-866d-181a94367c6b@github.com>

On Wed, 12 Mar 2025 11:15:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust jdk.management/Lib.gmk
>
> src/java.management/share/native/libmanagement/VMManagementImpl.c line 41:
> 
>> 39:     jstring version_string = NULL;
>> 40: 
>> 41:     unsigned int major = ((unsigned int) jmm_version & 0x0FFF0000) >> 16;
> 
> Can you please revert this unrelated changes as well?

Sure, this was a mistake I re added the unused line but at the wrong position in the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991417236

From duke at openjdk.org  Wed Mar 12 13:57:43 2025
From: duke at openjdk.org (snake66)
Date: Wed, 12 Mar 2025 13:57:43 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v2]
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

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

  Set ICONV_* flags for aix and macosx only

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23995/files
  - new: https://git.openjdk.org/jdk/pull/23995/files/c9382788..d4c4cca5

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

  Stats: 28 lines in 4 files changed: 2 ins; 11 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23995/head:pull/23995

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

From jiangli at openjdk.org  Wed Mar 12 14:43:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Mar 2025 14:43:09 GMT
Subject: RFR: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <Cd4HwT3pkU_8EsRHOszo9birQoXmCWbEhqAo1kPeCRw=.28bcd601-1d63-499c-8c83-136cef08fb77@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
 <Cd4HwT3pkU_8EsRHOszo9birQoXmCWbEhqAo1kPeCRw=.28bcd601-1d63-499c-8c83-136cef08fb77@github.com>
Message-ID: <oqbgid7lwa5ThLnGNkjI_9fCa3hgHHjO42ckcOBJsVA=.c9bf399f-6826-4321-823b-bf320a0890af@github.com>

On Mon, 10 Mar 2025 11:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks
>
> With that confirmation, I think we should go on with the `ONLY_EXPORTED` solution instead. 
> 
> If needed, we can revisit this in the future, to discuss how we should handle an optional library like libjsig. But that requires a complete solution througout the jmod/jlink pipeline to be meaningful.

Thanks, @magicus!

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

PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2718123902

From jiangli at openjdk.org  Wed Mar 12 14:43:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Mar 2025 14:43:09 GMT
Subject: Integrated: 8351309:
 test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk
In-Reply-To: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
References: <SK3yH0HoHFm_CdeOYKIqja6iOVQ2ec6lOotFwMRyek4=.25ad2cca-c038-4646-8c5f-a63f0699446c@github.com>
Message-ID: <V7qWf7Nd9fJBIWkW2MqgHaUN1qgbDVAusFT9GL35ceM=.baa4c28f-8ac9-4c21-a81e-5980b4279907@github.com>

On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that excludes `libjsig` from being statically linked with `static-jdk` `java` launcher by default. Please see details in https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks

This pull request has now been integrated.

Changeset: a21fa463
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a21fa463c4f8d067c18c09a072f3cdfa772aea5e
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8351309: test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java fails on static-jdk

Reviewed-by: manc, ihse, stuefe

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

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

From mbaesken at openjdk.org  Wed Mar 12 14:57:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 14:57:29 GMT
Subject: RFR: 8351277: Remove pipewire from AIX build
Message-ID: <Jq29RmMXyv4hUHLGREapqAOD3Dq9fbSAgNBnzOPIDfk=.1e73b3cc-ce6f-49a5-abb6-81b5fd21d321@github.com>

Seems Wayland is not supported on AIX, so we most likely do not need to build pipewire on AIX and can remove it from the build.
Reason is that pipewire updates can break the AIX build, so better avoid it if possible.

To check if it works, I move the 'pipewire/include' folder away, and the build still worked on AIX.

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

Commit messages:
 - JDK-8351277

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

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

From clanger at openjdk.org  Wed Mar 12 16:04:05 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 12 Mar 2025 16:04:05 GMT
Subject: RFR: 8351842: Test issues on Windows with combination of
 --enable-linkable-runtime and --with-external-symbols-in-bundles=public
Message-ID: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>

This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.

The problem is that whith this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols file named <binary-name>.pdb. The second set is a stripped debug symbols file called <binary-name>.stripped.pdb which has less information but enought to present line numbers in hs-err files.

During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.

With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.

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

Commit messages:
 - JDK-8351842

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

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

From ihse at openjdk.org  Wed Mar 12 16:58:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 16:58:55 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v2]
In-Reply-To: <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>
Message-ID: <Q9whAUJRCDUNFdG51wTnWdt6DTah2gz4H02IbF-c7nM=.b653c747-7ae8-4e6a-847e-792f44ae38c5@github.com>

On Wed, 12 Mar 2025 13:57:43 GMT, snake66 <duke at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set ICONV_* flags for aix and macosx only

Also, to double check, are the new variables `ICONV_CFLAGS` and `ICONV_LDFLAGS` going to be non-empty on BSD? There is no reason to introduce a variable for completeness sake, if it is never going to have any value. But it is fully okay if they are empty now, but will have a value for BSD.

make/modules/jdk.jdwp.agent/Lib.gmk line 76:

> 74:         java.base:libjava, \
> 75:     JDK_LIBS := java.base:libjvm, \
> 76:     LIBS_linux := $(LIBDL), \

Something got wrong here. You should have kept the LIBS_linux line, and the new LIBS line should be `LIBS := $(ICONV_LIBS)`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2718530308
PR Review Comment: https://git.openjdk.org/jdk/pull/23995#discussion_r1991917140

From ihse at openjdk.org  Wed Mar 12 17:19:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 17:19:16 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
Message-ID: <Zru6TSjWy97mEt5blgBMctBBvMTc3d8Xbrwf4n1ZhHE=.77dfb0cc-6f01-4d69-b108-26429e7b78a4@github.com>

On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move code back in VMManagementImpl

Marked as reviewed by ihse (Reviewer).

I have run this through our CI system and it looks good!

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

PR Review: https://git.openjdk.org/jdk/pull/23966#pullrequestreview-2679287511
PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2718582751

From ihse at openjdk.org  Wed Mar 12 17:19:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 17:19:58 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
Message-ID: <kraPGXIw02468QtQCqSv_YF3lhawdlWS8GjFElXKTy0=.fa45d2b0-85be-42e3-8fa8-3eb93ee28572@github.com>

On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make editorconfig hotspot specific

src/hotspot/.editorconfig line 1:

> 1: [*.{cpp,hpp,c,h}]

There are no C files in Hotspot, nor should there ever be. (There are a handful of .h files, though, for interop purposes)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23693#discussion_r1991956206