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: References: Message-ID: On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou 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: References: Message-ID: On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou 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: References: Message-ID: On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou 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: References: Message-ID: On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou 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 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: References: <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com> Message-ID: On Fri, 28 Feb 2025 10:28:57 GMT, Kim Barrett 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: References: Message-ID: <6q40Il3VVyRfWHyioQitI7wGXZU9A56L7L1wQtbx0wk=.05037eb9-47eb-47dc-b6a0-17a5894eb76d@github.com> On Wed, 11 Dec 2024 21:14:04 GMT, Magnus Ihse Bursie 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=, 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 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: 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: References: <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com> Message-ID: On Fri, 28 Feb 2025 10:28:57 GMT, Kim Barrett 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: References: Message-ID: <3Tg96OBVPqcbH7MN87yGQIWDGVxjKHj4ydMqfezYuow=.23648574-ec3c-433a-8650-a13027cedc70@github.com> On Tue, 4 Mar 2025 11:31:03 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Tue, 4 Mar 2025 11:31:03 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Tue, 4 Mar 2025 11:31:03 GMT, Magnus Ihse Bursie 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: References: Message-ID: <-x8LLP7coXLTiNCGuqPsk_t6KwPHW696nAuvwPM091s=.42708b7c-c827-43f6-9c61-3cd603476e2b@github.com> On Tue, 4 Mar 2025 14:53:13 GMT, Magnus Ihse Bursie 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: 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: 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: References: Message-ID: On Tue, 4 Mar 2025 11:31:03 GMT, Magnus Ihse Bursie 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 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: References: Message-ID: On Tue, 4 Mar 2025 16:22:43 GMT, SendaoYan 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: 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: References: Message-ID: > 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: References: Message-ID: <_uwdzQlIagCPL2gs-PrTxHBbM_WYcEX8a1dJdBH-mJQ=.0df2bf17-8ba8-44a7-9577-3afdc7481798@github.com> On Tue, 4 Mar 2025 17:16:41 GMT, Erik Joelsson 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: References: Message-ID: > 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: References: Message-ID: On Tue, 4 Mar 2025 17:17:32 GMT, Erik Joelsson 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: References: Message-ID: On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken 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: 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: References: Message-ID: On Wed, 5 Mar 2025 07:21:17 GMT, SendaoYan 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: References: Message-ID: On Wed, 5 Mar 2025 07:32:32 GMT, David Holmes 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: References: Message-ID: On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken 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: References: Message-ID: On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken 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: References: Message-ID: On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken 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: References: Message-ID: On Tue, 4 Mar 2025 16:11:22 GMT, Matthias Baesken 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 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: References: Message-ID: <1Lkzsid1vE9sXmyoP-6_2FJN9RUkOJEKbrYdLVTHIAI=.b26c3b8d-13f7-45fe-b20b-00fac416b2ee@github.com> On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar 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: References: Message-ID: <4TNkmn7EQo0ptD0or5DagwYjdjRvnbpPTXGJZyE6D4Y=.4bdd7cf7-b21e-4c40-8ad6-ea96086c017b@github.com> On Wed, 5 Mar 2025 02:10:34 GMT, SendaoYan 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: References: Message-ID: On Wed, 5 Mar 2025 07:54:51 GMT, SendaoYan 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: 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: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: References: Message-ID: <_zgC1NLNsTUH7R25xkfGEfh0f2IOJllcUFjvrBeY7ig=.7c026edc-a5f6-46e7-a480-ef8614feacf6@github.com> On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar 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: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: References: Message-ID: <8UpKLmwCBMscNGtKyktL_h1aBYo6uzB3kYJOWeJIugA=.78c737ec-e212-4458-a009-79867ad260e5@github.com> On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: References: Message-ID: <47x-CN3ZcoOHt0rkLBnoWGqN5WgRqng0oHra1AL4Gpc=.1a9274b8-ad40-4958-88c9-f1df68d00fb0@github.com> On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar 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: <_zgC1NLNsTUH7R25xkfGEfh0f2IOJllcUFjvrBeY7ig=.7c026edc-a5f6-46e7-a480-ef8614feacf6@github.com> Message-ID: On Wed, 5 Mar 2025 19:00:49 GMT, Harshitha Onkar 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: References: Message-ID: On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar 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: 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: 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: References: 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 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: References: Message-ID: <5ztalawYQsCNUsfzWyR_b5YVFWbDNzoHVUA4ycRjvRs=.42fd2b02-462f-4803-9d3b-2b907121c5be@github.com> On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> Message-ID: On Wed, 5 Mar 2025 23:19:50 GMT, Vladimir Ivanov 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: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: <4TNkmn7EQo0ptD0or5DagwYjdjRvnbpPTXGJZyE6D4Y=.4bdd7cf7-b21e-4c40-8ad6-ea96086c017b@github.com> Message-ID: On Wed, 5 Mar 2025 14:10:07 GMT, Erik Joelsson 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: References: Message-ID: On Tue, 4 Mar 2025 16:22:43 GMT, SendaoYan 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 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: References: Message-ID: On Wed, 5 Mar 2025 14:12:54 GMT, Erik Joelsson 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: References: Message-ID: On Wed, 5 Mar 2025 07:21:17 GMT, SendaoYan 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: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: References: Message-ID: On Wed, 5 Mar 2025 08:41:06 GMT, Matthias Baesken 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: References: Message-ID: <7xslrGte187xJy22qg_3aY5Cwx-dwEumw5hGaYXhSzk=.95d0c93a-d812-48de-a276-a1939ac2f407@github.com> On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> Message-ID: On Thu, 6 Mar 2025 00:16:12 GMT, Vladimir Ivanov 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: 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 [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: References: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> Message-ID: On Thu, 6 Mar 2025 09:48:47 GMT, Aleksey Shipilev 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: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: Message-ID: On Thu, 6 Mar 2025 10:39:27 GMT, snake66 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 > > [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: References: Message-ID: On Thu, 6 Mar 2025 12:46:25 GMT, David Holmes 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: References: Message-ID: On Thu, 6 Mar 2025 10:39:27 GMT, snake66 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 > > [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: References: Message-ID: On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann 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: References: Message-ID: On Thu, 6 Mar 2025 10:39:27 GMT, snake66 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 > > [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: References: Message-ID: On Thu, 6 Mar 2025 14:21:08 GMT, Erik Joelsson 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: References: Message-ID: On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro 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 >> >> [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: References: Message-ID: On Thu, 6 Mar 2025 10:39:27 GMT, snake66 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 > > [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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: Message-ID: On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann 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: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: References: Message-ID: On Thu, 6 Mar 2025 16:18:50 GMT, Magnus Ihse Bursie 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: <7xslrGte187xJy22qg_3aY5Cwx-dwEumw5hGaYXhSzk=.95d0c93a-d812-48de-a276-a1939ac2f407@github.com> Message-ID: On Thu, 6 Mar 2025 05:55:48 GMT, Man Cao 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: References: Message-ID: <1xDhCbB5y6lKeTsljSaXQIctUdhLeZYMZc3ttv3CCAY=.e32e38b6-8431-4fa9-9b49-8fb305a744aa@github.com> On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro 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 >> >> [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: References: Message-ID: On Thu, 6 Mar 2025 15:56:43 GMT, Magnus Ihse Bursie 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 >> >> [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: References: Message-ID: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com> On Thu, 6 Mar 2025 14:15:38 GMT, Erik Joelsson 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 >> >> [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: References: Message-ID: On Thu, 6 Mar 2025 12:37:52 GMT, David Holmes 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: References: Message-ID: On Thu, 6 Mar 2025 16:01:16 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: <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 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: References: Message-ID: On Thu, 6 Mar 2025 16:38:13 GMT, Aleksey Shipilev 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: References: Message-ID: On Thu, 6 Mar 2025 18:15:06 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: Message-ID: On Thu, 6 Mar 2025 18:49:54 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Thu, 6 Mar 2025 18:57:48 GMT, Henry Jen 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: Message-ID: On Thu, 6 Mar 2025 20:20:59 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: Message-ID: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie 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: References: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> Message-ID: On Thu, 6 Mar 2025 09:48:47 GMT, Aleksey Shipilev 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: References: Message-ID: On Thu, 6 Mar 2025 18:23:24 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Thu, 6 Mar 2025 17:42:04 GMT, Jiangli Zhou 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: References: Message-ID: On Thu, 6 Mar 2025 19:22:23 GMT, Jiangli Zhou 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: References: Message-ID: On Thu, 6 Mar 2025 21:45:29 GMT, Jiangli Zhou 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: 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: References: Message-ID: On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern 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: References: Message-ID: On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: Message-ID: On Thu, 6 Mar 2025 19:22:23 GMT, Jiangli Zhou 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: References: Message-ID: On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern 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: References: Message-ID: On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern 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: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> Message-ID: On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes 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: References: Message-ID: On Sat, 11 Mar 2023 16:07:54 GMT, Julian Waters 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: 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 {} }: 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: 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: References: <4TNkmn7EQo0ptD0or5DagwYjdjRvnbpPTXGJZyE6D4Y=.4bdd7cf7-b21e-4c40-8ad6-ea96086c017b@github.com> Message-ID: On Thu, 6 Mar 2025 01:40:43 GMT, SendaoYan 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: References: Message-ID: On Fri, 7 Mar 2025 12:00:24 GMT, Magnus Ihse Bursie 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: References: 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 {} }: > > 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: 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: References: Message-ID: On Fri, 7 Mar 2025 07:21:43 GMT, David Holmes 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: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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: References: Message-ID: On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters 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: References: Message-ID: On Fri, 7 Mar 2025 15:11:09 GMT, Magnus Ihse Bursie 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: References: Message-ID: <7lj62NHzOSzqL-1MEvHLg228x2l3rVABVe8weAnA-EQ=.ed5dba84-190a-4204-b80c-b23be62a9dc5@github.com> On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou 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: References: Message-ID: <7kBnYGrIMJOk_HHsxrFqkVus4rLt0DkWRLsHyAsMmps=.55561218-81fe-4d28-9ef0-39f837ab84e6@github.com> On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters 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: <786e3ed3-4050-43bf-829a-0caf2b7236b9@oracle.com> Message-ID: 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 {} }: > > 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: 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> <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: 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: References: 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: <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: References: Message-ID: On Fri, 7 Mar 2025 07:41:42 GMT, David Holmes 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: References: Message-ID: On Fri, 7 Mar 2025 09:44:38 GMT, Thomas Stuefe 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: References: Message-ID: On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou 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: 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: References: 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 > > [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: References: Message-ID: <9UFdT-v-9fSiAc2xdLacWIl73p51u3gevDuuXSNN6IA=.3fc868ee-04e5-49e1-b666-e2a74d51672c@github.com> On Wed, 5 Mar 2025 02:10:34 GMT, SendaoYan 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: References: Message-ID: On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern 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: References: Message-ID: On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern 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: References: Message-ID: On Fri, 7 Mar 2025 09:22:44 GMT, Doug Simon 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: References: Message-ID: On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann 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 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 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: References: Message-ID: > 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: References: Message-ID: On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern 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 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: References: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> Message-ID: <5PZgChiJciTkkZIUnXtTWZMB4ZxN8DmZHUWBFt9ptBw=.77216c80-a470-4e20-908e-7e419404e607@github.com> On Fri, 7 Mar 2025 07:18:27 GMT, David Holmes 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: References: Message-ID: > 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: References: Message-ID: <3jbKFXHYH2mgyYOQjn2rfGm0IpIwH377DuDrZAY4X7w=.8d0767f3-7190-4396-824a-d55e6a61f479@github.com> On Fri, 7 Mar 2025 15:06:18 GMT, Magnus Ihse Bursie 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: References: Message-ID: <8GSZRPDK4WLn6bHC2D2Ow47a-xd9NzCN6azXs2aDp_g=.47762983-f579-4ea1-b22e-abbd1740e6d3@github.com> On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev 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: References: Message-ID: On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev 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: References: Message-ID: On Mon, 10 Mar 2025 09:03:40 GMT, David Linus Briemann 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: References: Message-ID: On Mon, 10 Mar 2025 08:57:11 GMT, David Linus Briemann 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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: References: Message-ID: On Mon, 10 Mar 2025 08:57:11 GMT, David Linus Briemann 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: References: Message-ID: On Wed, 5 Mar 2025 02:10:34 GMT, SendaoYan 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: <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 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 >> >> [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: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> Message-ID: On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes 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: References: Message-ID: On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou 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: 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: 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: References: Message-ID: On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev 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: References: Message-ID: On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt 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: References: Message-ID: On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev 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: References: Message-ID: On Mon, 10 Mar 2025 11:03:30 GMT, Kim Barrett 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: <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 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 >> >> [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: References: Message-ID: On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt 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: References: Message-ID: 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: 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: References: 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: 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: References: Message-ID: On Thu, 6 Mar 2025 13:27:15 GMT, snake66 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: References: Message-ID: * 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: 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: <3jbKFXHYH2mgyYOQjn2rfGm0IpIwH377DuDrZAY4X7w=.8d0767f3-7190-4396-824a-d55e6a61f479@github.com> Message-ID: On Mon, 10 Mar 2025 09:46:38 GMT, Aleksey Shipilev 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: References: 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: 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: 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: References: Message-ID: On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken 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: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com> Message-ID: On Sat, 8 Mar 2025 13:39:44 GMT, snake66 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 >> >> [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: References: Message-ID: <-oM28zHPAbcyBdq_BOkIfj4rXs8tckUqQD6Vto-wdbU=.6b9a75b3-db1b-4468-a689-73b94fb87f04@github.com> On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt 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: References: Message-ID: On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt 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 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: References: Message-ID: On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken 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: References: Message-ID: On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar 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 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: References: Message-ID: > 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: References: Message-ID: On Fri, 7 Mar 2025 09:22:44 GMT, Doug Simon 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: References: Message-ID: On Mon, 10 Mar 2025 11:03:06 GMT, Magnus Ihse Bursie 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: References: Message-ID: <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com> On Mon, 10 Mar 2025 17:32:07 GMT, Erik Joelsson 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: <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 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 /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: 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: References: Message-ID: On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev 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: References: Message-ID: On Mon, 10 Mar 2025 14:33:14 GMT, Artur Barashev 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: References: Message-ID: > 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: <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com> Message-ID: On Mon, 10 Mar 2025 18:51:53 GMT, Matthias Baesken 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: References: Message-ID: > 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: References: Message-ID: On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann 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: References: Message-ID: On Tue, 11 Mar 2025 09:04:59 GMT, Matthias Baesken 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: References: Message-ID: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com> On Tue, 11 Mar 2025 09:04:59 GMT, Matthias Baesken 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: References: Message-ID: <3B8pMV5sb2cg79JQ1D5Elg4q_FpVpjU3ccyA8WJ8mcg=.6379566a-697c-4af9-85e2-8252f01cae3b@github.com> On Tue, 11 Mar 2025 11:54:29 GMT, Kevin Walls 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: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com> Message-ID: On Tue, 11 Mar 2025 13:18:55 GMT, Kevin Walls 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: <3B8pMV5sb2cg79JQ1D5Elg4q_FpVpjU3ccyA8WJ8mcg=.6379566a-697c-4af9-85e2-8252f01cae3b@github.com> Message-ID: On Tue, 11 Mar 2025 13:36:42 GMT, Matthias Baesken 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: References: Message-ID: > 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: References: Message-ID: On Tue, 11 Mar 2025 14:14:16 GMT, Matthias Baesken 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: References: Message-ID: On Thu, 6 Mar 2025 10:39:27 GMT, snake66 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 > > [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4 This pull request has now been integrated. Changeset: b957e5ed Author: Harald Eilertsen 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: References: Message-ID: On Tue, 11 Mar 2025 15:04:58 GMT, Kevin Walls 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: References: Message-ID: <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com> On Tue, 11 Mar 2025 15:04:58 GMT, Kevin Walls 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: References: Message-ID: <-yHVILTohqAwtW9PVPJ2TEE3cIaKP3EsjRmYCnvWwtY=.0a5f897f-4e3a-40a3-86f3-e785c2ec9cee@github.com> On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt 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: References: Message-ID: <5irTdPcTdpBrzwzWUiAaZqHKbGINiONFtIYDLIguyws=.1f241454-7cae-4f45-9383-57953b37de8b@github.com> On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev 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: References: Message-ID: On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann 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: <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com> Message-ID: On Tue, 11 Mar 2025 15:19:24 GMT, Matthias Baesken 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: References: Message-ID: On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt 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: References: Message-ID: On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt 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 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: References: Message-ID: On Tue, 11 Mar 2025 14:14:16 GMT, Matthias Baesken 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: References: Message-ID: <1xtq0lAHkDTiuHf10aKQsVeMAna7KULfQWUWsoiamZA=.755e8587-39d2-4db6-8f11-848f834580dc@github.com> On Mon, 10 Mar 2025 18:28:44 GMT, Jiangli Zhou 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: References: Message-ID: On Mon, 10 Mar 2025 18:39:46 GMT, Jiangli Zhou 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: References: Message-ID: On Mon, 10 Mar 2025 11:03:06 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev 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> <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: 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 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: 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: References: Message-ID: On Tue, 11 Mar 2025 19:22:34 GMT, snake66 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: References: Message-ID: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com> On Tue, 11 Mar 2025 19:35:45 GMT, Erik Joelsson 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: References: Message-ID: On Mon, 16 Dec 2024 22:03:59 GMT, Artur Barashev 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 Committer: Weijun Wang 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: References: Message-ID: On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev 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: References: <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com> Message-ID: On Tue, 11 Mar 2025 15:59:09 GMT, Erik Joelsson 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: References: Message-ID: > 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: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com> Message-ID: On Tue, 11 Mar 2025 13:18:55 GMT, Kevin Walls 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: References: Message-ID: On Wed, 12 Mar 2025 11:15:02 GMT, Matthias Baesken 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: References: <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com> Message-ID: <75SREzlDoYwqWP8IeEVKUH6x8ZXagK6nDUkULmBnid0=.eda00d2d-e721-44f9-b890-edad0fe3f5b7@github.com> On Tue, 11 Mar 2025 09:07:40 GMT, Matthias Baesken 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: References: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@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 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: References: Message-ID: On Mon, 10 Mar 2025 18:28:44 GMT, Jiangli Zhou 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: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com> Message-ID: On Tue, 11 Mar 2025 19:45:58 GMT, snake66 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: References: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com> Message-ID: On Wed, 12 Mar 2025 12:12:37 GMT, Magnus Ihse Bursie 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: References: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com> Message-ID: On Wed, 12 Mar 2025 12:15:18 GMT, Magnus Ihse Bursie 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: References: Message-ID: > 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: References: Message-ID: <7htIj8fq8F1fm1ldEYSZ7qbjGUwmsJoxidI_2inw9FI=.48926cd9-79b4-4674-866d-181a94367c6b@github.com> On Wed, 12 Mar 2025 11:15:01 GMT, Magnus Ihse Bursie 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: References: Message-ID: > 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: References: Message-ID: On Mon, 10 Mar 2025 11:03:06 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou 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 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: 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: 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 .pdb. The second set is a stripped debug symbols file called .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: References: Message-ID: On Wed, 12 Mar 2025 13:57:43 GMT, snake66 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: References: Message-ID: On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken 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: References: Message-ID: On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann 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 From duke at openjdk.org Wed Mar 12 19:54:55 2025 From: duke at openjdk.org (David Linus Briemann) Date: Wed, 12 Mar 2025 19:54:55 GMT Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common settings automatically: indent, trim trailing whitespace [v3] In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 17:17:41 GMT, Magnus Ihse Bursie wrote: >> 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) Yes I saw that there are no C files but added it for symmetry with the H files. I don't think it hurts here but I can also remove it. Do you think it should be removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23693#discussion_r1992197721 From erikj at openjdk.org Wed Mar 12 20:02:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 12 Mar 2025 20:02:53 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 15:57:40 GMT, Christoph Langer wrote: > 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 .pdb. The second set is a stripped debug symbols file called .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. What happens with the local debugging experience in the exploded image if you configure with ` --with-external-symbols-in-bundles=public`? Then the full debug symbols are only present in the *.full.pdb files. Will the debugger tools on Windows know automatically how to resolve that, or will this configuration be inconvenient for local dev/debug usecases? As I remember it, the current scheme was chosen to put the "full" pdb files as *.pdb in the exploded image whenever possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2718964639 From sgehwolf at openjdk.org Wed Mar 12 20:06:52 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 12 Mar 2025 20:06:52 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 15:57:40 GMT, Christoph Langer wrote: > 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 .pdb. The second set is a stripped debug symbols file called .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. Nice find! This sounds like a bug in the build machinery. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2718972286 From sgehwolf at openjdk.org Wed Mar 12 20:09:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 12 Mar 2025 20:09:51 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 20:00:29 GMT, Erik Joelsson wrote: > What happens with the local debugging experience in the exploded image if you configure with ` --with-external-symbols-in-bundles=public`? Do we care about the local debugging experience in that case? I'd argue if good debug experience is what is wanted, you'd omit `--with-external-symbols-in-bundles=public` configure option? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2718979523 From erikj at openjdk.org Wed Mar 12 20:43:51 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 12 Mar 2025 20:43:51 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 20:07:21 GMT, Severin Gehwolf wrote: > > What happens with the local debugging experience in the exploded image if you configure with ` --with-external-symbols-in-bundles=public`? > > Do we care about the local debugging experience in that case? I'd argue if good debug experience is what is wanted, you'd omit `--with-external-symbols-in-bundles=public` configure option? I think this can easily be turned around as, do we care about being able to run certain tests using the image in the build directory, rather than using an unpacked bundle, which is what we are actually shipping? The underlying issue here is that the image we produce in the build output directory isn't exactly what we then bundle up and ship. The image is trying to serve multiple purposes and compromises were made a long time ago which we are still carrying today. I'm not sure what the right answer is. We have contemplated enabling `--with-external-symbols-in-bundles=public` for Oracle builds, but with this change, I think it would be a lot less likely to happen, because JDK developers would have to actively opt out of it if we made it default for us. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2719078009 From ihse at openjdk.org Wed Mar 12 22:23:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 12 Mar 2025 22:23:53 GMT Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common settings automatically: indent, trim trailing whitespace [v3] In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 19:51:51 GMT, David Linus Briemann wrote: >> 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) > > Yes I saw that there are no C files but added it for symmetry with the H files. I don't think it hurts here but I can also remove it. Do you think it should be removed? I think that is rather up to the Hotspot folks to have an opinion on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23693#discussion_r1992376183 From clanger at openjdk.org Thu Mar 13 07:39:20 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 13 Mar 2025 07:39:20 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: > 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Fix tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24012/files - new: https://git.openjdk.org/jdk/pull/24012/files/37037f4f..f560fd21 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24012&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24012&range=00-01 Stats: 13 lines in 2 files changed: 8 ins; 0 del; 5 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 clanger at openjdk.org Thu Mar 13 07:52:52 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 13 Mar 2025 07:52:52 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests First of all, after giving this a spin in our testing I found that I needed to address two new test problems. If we go with this change, we need to align JmodExcludedFiles with the new naming (*.full.pdb instead of *.stripped.pdb), otherwise this test would fail in ` --with-external-symbols-in-bundles=public` mode. Also, with the standard pdb file not being the stripped one, the gtest `dll_address_to_function_and_library_name` fails in its current form because it doesn't print the symbol name any more but only an address. So I weakened the condition on Windows a little to make the test pass. Probably something for the eyes of @tstuefe. Now, regarding the principal point opened by Erik, I think it is somehow valid. If we were to build with `--with-external-symbols-in-bundles=public`, the debugging experience for a developer is a bit worse. On the other hand, I agree with Severin, developers should probably not use this for their local builds, it's rather a shipment configuration. The alternative would be to exclude some 50+ test cases when using linkable runtime on Windows, which is no good either. Or should there be an alternative image directory used for these kinds of test? Or should jlink get some workaround coding to check whether *stripped.pdb files are present and try to prefer these when building runtimes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2720268571 From mbaesken at openjdk.org Thu Mar 13 08:51:05 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Mar 2025 08:51:05 GMT Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings [v5] In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken 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 Thanks for the review and testing in your CI ! Kevin/Erik , are you fine with the change as it is now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2720437258 From ihse at openjdk.org Thu Mar 13 09:26:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 13 Mar 2025 09:26:57 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests Please refrain from integrating this until we get consensus on the principal issue here, as pointed out by Erik. This is not just a build issue, it is an issue of differing expectations. It might even be that the solution is a modification in jlink rather than the build system. My take is that we should be able to both test and debug what we ship. I can't say straight up how to solve that, but I believe that if there is a will, there is a way; we just have to try harder to find it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2720552884 PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2720556790 From ihse at openjdk.org Thu Mar 13 09:31:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 13 Mar 2025 09:31:57 GMT Subject: RFR: 8351277: Remove pipewire from AIX build In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 14:52:10 GMT, Matthias Baesken wrote: > 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. Can you include a revert of JDK-8349751, which is not needed anymore after this change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2720571221 From magnus.ihse.bursie at oracle.com Thu Mar 13 09:39:29 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Mar 2025 10:39:29 +0100 Subject: [Proposal] Add code signing on Windows to the JDK build system In-Reply-To: <4e501adc-aed7-4c56-8157-155b87b732b4@redhat.com> References: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com> <79bc54ec-fd5d-4803-914d-01c64ef88a98@redhat.com> <1f1fd802-72e0-4b27-9a77-9d9ed913caf3@oracle.com> <37182570-6ec8-47cc-8560-b3014f07df2c@oracle.com> <4e501adc-aed7-4c56-8157-155b87b732b4@redhat.com> Message-ID: On 2025-03-11 20:29, Frederic Thevenet wrote: > 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? Hm, that is definitely an interesting take. I'm a big fan of "right-sizing" generalization; I think both too much and too little generalization is detrimental. My gut feeling right now is that we should keep this focused on what it is, a way to allow signing. It will make the functionality discoverable by other parties that would like to add their own signing script; a general "hook" system might not. But it's good to keep in mind in case any future, non-signing needs arise. I was more thinking along the lines that the current macOS signing could be considered/rewritten in terms of a "signing hook", with the exception that we also ship a default implementation alongside in the build system. If we do that right, we could probably retrofit Oracle's internal macOS signing logic into the same framework, which would be nice. But then again, that is definitely feature creep wrt to your original request. So maybe we can come back and revisit that thought later. /Magnus > > 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: 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 kevinw at openjdk.org Thu Mar 13 09:50:12 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 13 Mar 2025 09:50:12 GMT Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings [v5] In-Reply-To: References: Message-ID: <-S_7YK4aaJ5iRuClElccYN_8PMc06Bj5ye5EyWv7CHY=.fe2ff008-ca98-4540-9d99-2b5c463a7cb1@github.com> On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken 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 Yes looks good. I'm seeing -O3 in a Linux release build and -O2 in a fastdebug build. I see the release build libmanagement.so is 48 bytes smaller than before, both around 25k, so no real difference. Didn't see any new problems in all the management tests. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23966#pullrequestreview-2681208349 From duke at openjdk.org Thu Mar 13 10:02:59 2025 From: duke at openjdk.org (snake66) Date: Thu, 13 Mar 2025 10:02:59 GMT Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv [v2] In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 16:56:32 GMT, Magnus Ihse Bursie wrote: > Also, to double check, are the new variables `ICONV_CFLAGS` and `ICONV_LDFLAGS` going to be non-empty on BSD? Yes, the current BSD port has the following in `libraries.m4`: if test "x$OPENJDK_TARGET_OS" = "xbsd"; then if test "x$OPENJDK_TARGET_OS_ENV" = "xbsd.openbsd"; then ICONV_CFLAGS="-I/usr/local/include" ICONV_LDFLAGS="-L/usr/local/lib" ICONV_LIBS=-liconv elif test "x$OPENJDK_TARGET_OS_ENV" = "xbsd.freebsd"; then ICONV_CFLAGS=-DLIBICONV_PLUG ICONV_LDFLAGS= ICONV_LIBS= else ICONV_CFLAGS= ICONV_LDFLAGS= ICONV_LIBS= fi else ICONV_CFLAGS= ICONV_LDFLAGS= ICONV_LIBS=-liconv fi AC_SUBST(ICONV_CFLAGS) AC_SUBST(ICONV_LDFLAGS) AC_SUBST(ICONV_LIBS) So strictly speaking we only need `ICONV_CFLAGS` for FreeBSD, and `ICONV_LIBS` for aix and macosx. That is if we don't want to include OpenBSD support at this time. > 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)`. Ooops, I'll fix! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2720660907 PR Review Comment: https://git.openjdk.org/jdk/pull/23995#discussion_r1993169985 From fthevenet at openjdk.org Thu Mar 13 10:23:53 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Thu, 13 Mar 2025 10:23:53 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 20:00:29 GMT, Erik Joelsson wrote: > What happens with the local debugging experience in the exploded image if you configure with ` --with-external-symbols-in-bundles=public`? Then the full debug symbols are only present in the *.full.pdb files. Will the debugger tools on Windows know automatically how to resolve that, or will this configuration be inconvenient for local dev/debug usecases? As I remember it, the current scheme was chosen to put the "full" pdb files as *.pdb in the exploded image whenever possible. FWIW, from my work on https://github.com/openjdk/jdk/pull/16039 I remember verifying that debuggers on Windows do not rely on the filenames of pdb files to match the symbols and binaries, so AFAIK, the fact that the symbols for, say, `jvm.dll`, will be in a file named `jvm.dll.full.pdb` instead of `jvm.dll.pdb` does not imply it won't be found by the debugger (i.e. it used to be in a file named `jvm.pdb`) Now, if I understand the proposed change correctly, the exploded image will contain two distinct `.pdb` files for each binaries, so a question remain about how a debugger might decide to choose one over the other, but do we know for sure that this indeed affect the right symbols to be picked up? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2720726016 From sgehwolf at openjdk.org Thu Mar 13 10:30:58 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 13 Mar 2025 10:30:58 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests Maybe, I misunderstood how this works... I'm not a Windows person. > My take is that we should be able to both test and debug what we ship. Agreed. What I don't understand why this inconsistency is being done to begin with? To appease testing maybe? Is that the idea? > 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. I'll add here that the implementation of JEP 493, does nothing special. It takes what's in the JMODs *at build time* when `jlink` is being run and uses that as the "source of truth" when it comes to hash sums. It sounds to me that when `jlink` runs during the build it only sees `*.stripped.pdb` files (renamed as `*.pdb`). If something is being done **after** the `jdk` image has been created (by `jlink`) and changes files (like copying full `*.pdb` files over the stripped ones that are actually in the JMODs) then this is the root cause of this bug. Rightfully so, since the `*.pdb` files in the JDK image no longer match the ones in the JMOD files. Is that the case? @RealCLanger Could you please run these commands for me and let me know the output? Sorry, I don't know the windows equivalents of these: $ jmod extract --dir java.base-jmod-extract images\jmods\java.base.jmod $ sha512sum java.base-jmod-extract\bin\keytool.exe.pdb 5df21e93cd24a03e491debd469001fc73950812de2d2b5d6df0272b55e9d206b56a4332a9f77e19e8755da12dc43f1c353575503b1f53d3d894794e19632964a java.base-jmod-extract\bin\keytool.exe.pdb $ jimage extract --dir lib-modules-extract images\jdk\lib\modules $ grep keytool.exe.pdb lib-modules-extract\jdk.jlink\jdk\tools\jlink\internal\runtimelink\fs_java.base_files 6|0|5df21e93cd24a03e491debd469001fc73950812de2d2b5d6df0272b55e9d206b56a4332a9f77e19e8755da12dc43f1c353575503b1f53d3d894794e19632964a|bin\keytool.exe.pdb $ sha512sum images\jdk\bin\keytool.exe.pdb ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2720746544 From duke at openjdk.org Thu Mar 13 11:39:14 2025 From: duke at openjdk.org (snake66) Date: Thu, 13 Mar 2025 11:39:14 GMT Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv [v3] In-Reply-To: References: Message-ID: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@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: Unbreak libjdwp build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23995/files - new: https://git.openjdk.org/jdk/pull/23995/files/d4c4cca5..a9fdfef5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23995&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23995&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 mbaesken at openjdk.org Thu Mar 13 12:45:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Mar 2025 12:45:19 GMT Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings [v5] In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken 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 Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2721123753 From mbaesken at openjdk.org Thu Mar 13 12:45:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Mar 2025 12:45:19 GMT Subject: Integrated: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken wrote: > On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed. This pull request has now been integrated. Changeset: c3db6671 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/c3db667156f7e6b7d05c76370973b9f2db9f0d55 Stats: 12 lines in 2 files changed: 0 ins; 10 del; 2 mod 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings Reviewed-by: ihse, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/23966 From mbaesken at openjdk.org Thu Mar 13 13:06:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Mar 2025 13:06:38 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: References: Message-ID: > 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. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: remove AIX special handling from endian.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24009/files - new: https://git.openjdk.org/jdk/pull/24009/files/84740c96..e7941d37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 4 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 ihse at openjdk.org Thu Mar 13 13:06:38 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 13 Mar 2025 13:06:38 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 13:03:16 GMT, Matthias Baesken wrote: >> 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. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove AIX special handling from endian.h This looks good to me. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2681818338 From mbaesken at openjdk.org Thu Mar 13 13:06:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Mar 2025 13:06:39 GMT Subject: RFR: 8351277: Remove pipewire from AIX build In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 09:29:38 GMT, Magnus Ihse Bursie wrote: > Can you include a revert of JDK-8349751, which is not needed anymore after this change? Okay I removed the AIX code from endian.h . ------------- PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2721177888 From erikj at openjdk.org Thu Mar 13 13:29:57 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 13 Mar 2025 13:29:57 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests > I'll add here that the implementation of JEP 493, does nothing special. It takes what's in the JMODs _at build time_ when `jlink` is being run and uses that as the "source of truth" when it comes to hash sums. It sounds to me that when `jlink` runs during the build it only sees `*.stripped.pdb` files (renamed as `*.pdb`). If something is being done **after** the `jdk` image has been created (by `jlink`) and changes files (like copying full `*.pdb` files over the stripped ones that are actually in the JMODs) then this is the root cause of this bug. Rightfully so, since the `*.pdb` files in the JDK image no longer match the ones in the JMOD files. Is that the case? Yes, that is the root cause of this issue that I tried to allude to in my last comment. The "jdk image" that we produce in the build and run tests from isn't exactly what jlink produced, or what ends up inside the zip/tar.gz bundles. Historically we always put the debug symbols in that image, for developer convenience. When introducing the stripped/public pdb support, we managed to preserve this property of the jdk image. This is basically why in this case, the image isn't representative of the shipped product and the tests fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2721258333 From ihse at openjdk.org Thu Mar 13 13:31:59 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 13 Mar 2025 13:31:59 GMT Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv [v3] In-Reply-To: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com> References: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com> Message-ID: <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com> On Thu, 13 Mar 2025 11:39:14 GMT, snake66 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: > > Unbreak libjdwp build This looks good to me now. Then I think the current solution is fine. Even if OpenBSD is not the primary goal of your port, I see no reason to actively work against it either, so if it needs `ICONV_LDFLAGS` then we should include it. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23995#pullrequestreview-2681916914 PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721263178 From duke at openjdk.org Thu Mar 13 13:57:12 2025 From: duke at openjdk.org (duke) Date: Thu, 13 Mar 2025 13:57:12 GMT Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv [v3] In-Reply-To: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com> References: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com> Message-ID: On Thu, 13 Mar 2025 11:39:14 GMT, snake66 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: > > Unbreak libjdwp build @snake66 Your change (at version a9fdfef5f18c63deebd64f37825b8b733997c588) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721348961 From duke at openjdk.org Thu Mar 13 13:57:10 2025 From: duke at openjdk.org (snake66) Date: Thu, 13 Mar 2025 13:57:10 GMT Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv [v3] In-Reply-To: <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com> References: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com> <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com> Message-ID: On Thu, 13 Mar 2025 13:28:32 GMT, Magnus Ihse Bursie wrote: >> snake66 has updated the pull request incrementally with one additional commit since the last revision: >> >> Unbreak libjdwp build > > Then I think the current solution is fine. Even if OpenBSD is not the primary goal of your port, I see no reason to actively work against it either, so if it needs `ICONV_LDFLAGS` then we should include it. @magicus @erikj79 Thanks for the reviews and help! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721341294 From sgehwolf at openjdk.org Thu Mar 13 14:18:57 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 13 Mar 2025 14:18:57 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests Another angle of this is that as soon as a user runs `jlink` to produce a custom runtime the debugging experience will be different to the JDK they started out with. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2721421629 From honkar at openjdk.org Thu Mar 13 15:52:20 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 13 Mar 2025 15:52:20 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 Message-ID: Upgraded Libpng to v1.6.47 ------------- Commit messages: - unused-function added for gcc - libpng upgrade Changes: https://git.openjdk.org/jdk/pull/24021/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348598 Stats: 4982 lines in 23 files changed: 1913 ins; 2285 del; 784 mod Patch: https://git.openjdk.org/jdk/pull/24021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24021/head:pull/24021 PR: https://git.openjdk.org/jdk/pull/24021 From honkar at openjdk.org Thu Mar 13 15:52:20 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 13 Mar 2025 15:52:20 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 00:27:46 GMT, Harshitha Onkar wrote: > Upgraded Libpng to v1.6.47 make/modules/java.desktop/lib/ClientLibraries.gmk line 249: > 247: DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \ > 248: DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \ > 249: DISABLED_WARNINGS_clang_png.c := unused-function, \ This warning was disabled to fix the following build issue on linux and macOS. open/src/java.desktop/share/native/libsplashscreen/libpng/png.c:1558:1: error: 'png_icc_profile_error' defined but not used [-Werror=unused-function] [2025-03-12T23:57:44,575Z] 1558 | png_icc_profile_error(png_const_structrp png_ptr, png_const_charp name, [2025-03-12T23:57:44,575Z] | ^~~~~~~~~~~~~~~~~~~~~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24021#discussion_r1993813117 From erikj at openjdk.org Thu Mar 13 16:26:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 13 Mar 2025 16:26:56 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: <6d7nWOO0CaQYiTa0_Rt3PPR33R91gD4pKrnQBJK602w=.b0eb2f32-e4ee-4699-98b0-78e4b0c04f32@github.com> On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests I did a little bit of an experiment. When we link today, we supply this argument to define the main/full pdb file: "-pdb:$$($1_SYMBOLS_DIR)/$$($1_BASENAME).pdb" And in the case of `--with-external-symbols-in-bundles=public`, we also add this: "-pdbstripped:$$($1_SYMBOLS_DIR)/$$($1_BASENAME).stripped.pdb" Just checking the contents of the resulting dll using `strings`, we can see that a reference to the pdb file is stored: $ strings build/windows-x64/images/jdk/bin/verify.dll | grep pdb verify.dll.pdb This reference is the same wether I configure with `--with-external-symbols-in-bundles=public` or not, as in, strings does not find any `verify.dll.stripped.pdb` reference. Now with this patch, we instead supply: "-pdb:$$($1_SYMBOLS_DIR)/$$($1_BASENAME).full.pdb" "-pdbstripped:$$($1_SYMBOLS_DIR)/$$($1_BASENAME).pdb" And then the stored reference becomes: $ strings build/windows-x64-public-patch/images/jdk/bin/verify.dll | grep pdb verify.dll.full.pdb This is of course just an indication of what the Microsoft linker does and how the tools will interpret these libraries and executables. I haven't actually tested all the scenarios with debugging tools or generating hserr files. I do think it's enough to warrant a proper investigation before we change the `-pdb` flag to point to a filename other than `$$($1_BASENAME).pdb` though, as that could potentially have consequences for loading any kind of symbols in the final binaries. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2721877569 From mbaesken at openjdk.org Thu Mar 13 16:44:24 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Mar 2025 16:44:24 GMT Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings [v5] In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken 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 As pointed out already, we have a similar special setting here , should we also adjust this ? make/modules/java.base/lib/CoreLibraries.gmk-36-ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true) make/modules/java.base/lib/CoreLibraries.gmk:37: LIBVERIFY_OPTIMIZATION := LOW make/modules/java.base/lib/CoreLibraries.gmk-38-endif make/modules/java.base/lib/CoreLibraries.gmk-39- make/modules/java.base/lib/CoreLibraries.gmk-40-$(eval $(call SetupJdkLibrary, BUILD_LIBVERIFY, \ make/modules/java.base/lib/CoreLibraries.gmk-41- NAME := verify, \ make/modules/java.base/lib/CoreLibraries.gmk:42: OPTIMIZATION := $(LIBVERIFY_OPTIMIZATION), \ make/modules/java.base/lib/CoreLibraries.gmk-43- DISABLED_WARNINGS_gcc_check_code.c := unused-variable, \ make/modules/java.base/lib/CoreLibraries.gmk-44- DISABLED_WARNINGS_clang_check_code.c := unused-variable, \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2721937986 From erikj at openjdk.org Thu Mar 13 16:57:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 13 Mar 2025 16:57:53 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 00:27:46 GMT, Harshitha Onkar wrote: > Upgraded Libpng to v1.6.47 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24021#pullrequestreview-2682753294 From duke at openjdk.org Thu Mar 13 16:58:03 2025 From: duke at openjdk.org (snake66) Date: Thu, 13 Mar 2025 16:58:03 GMT Subject: Integrated: 8351323: Parameterize compiler and linker flags for iconv In-Reply-To: References: Message-ID: On Tue, 11 Mar 2025 19:22:34 GMT, snake66 wrote: > Allows for future support for platforms that require different flags for libiconv support. > > Sponsored-by: The FreeBSD Foundation This pull request has now been integrated. Changeset: 771e160d Author: Harald Eilertsen URL: https://git.openjdk.org/jdk/commit/771e160da4daa98bfe37bf1acba65454c088910c Stats: 35 lines in 5 files changed: 25 ins; 2 del; 8 mod 8351323: Parameterize compiler and linker flags for iconv Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.org/jdk/pull/23995 From clanger at openjdk.org Thu Mar 13 17:22:53 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 13 Mar 2025 17:22:53 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests Thanks Erik for your investigation. However, the failing gtest that I workarounded here seems to be an indication that this might not work since a method name can not be found. On the other hand, I did not check the implementation of os::print_function_and_library_name and whether it looks for some hard coded pdb name. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2722075785 From honkar at openjdk.org Thu Mar 13 17:24:43 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 13 Mar 2025 17:24:43 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v2] In-Reply-To: References: Message-ID: <5sGdMzQPXGXVMAIUeBZ9wLwKKRC6iDKNqzG4A48Osyo=.593739b1-42ee-47b2-b8df-2638743e1bc6@github.com> > Upgraded Libpng to v1.6.47 Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: header update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24021/files - new: https://git.openjdk.org/jdk/pull/24021/files/b8f10b8d..e1954bcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24021/head:pull/24021 PR: https://git.openjdk.org/jdk/pull/24021 From honkar at openjdk.org Thu Mar 13 17:30:33 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 13 Mar 2025 17:30:33 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3] In-Reply-To: References: Message-ID: > Upgraded Libpng to v1.6.47 Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: header update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24021/files - new: https://git.openjdk.org/jdk/pull/24021/files/e1954bcb..2f0cea2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24021&range=01-02 Stats: 82 lines in 16 files changed: 80 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24021/head:pull/24021 PR: https://git.openjdk.org/jdk/pull/24021 From kevinw at openjdk.org Thu Mar 13 17:44:12 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 13 Mar 2025 17:44:12 GMT Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings [v5] In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken 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 Yes seems likely the same history for libverify, so should be good to do the same update there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2722162206 From azvegint at openjdk.org Thu Mar 13 18:59:52 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 13 Mar 2025 18:59:52 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 17:30:33 GMT, Harshitha Onkar wrote: >> Upgraded Libpng to v1.6.47 > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > header update Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24021#pullrequestreview-2683085368 From fthevenet at openjdk.org Thu Mar 13 19:14:53 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Thu, 13 Mar 2025 19:14:53 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests I did some tests by building the JDK's master branch (e.g. *without* this patch) with `--with-external-symbols-in-bundles=public` and then renaming the generated `jvm.dll.pdb` to `jvm.dll.full.pdb`. I left `jvm.dll.stripped.pdb` unchanged. Then using [WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/) to debug jshell, I could confirm that in fact WinDbg could *not* load symbols for `jvm.dll` neither from `jvm.dll.full.pdb` nor from `jvm.dll.stripped.dll`, It would resort to what it calls "exported symbols" for this module, which you can't use for doing much. Then I renamed `jvm.dll.full.pdb` back to `jvm.dll.pdb` and restarted the debugger and confirmed I could now set a breakpoint in the source file and have the debugger step in and highlight source lines properly, as expected. Finally I named `jvm.dll.stripped.pdb` as `jvm.dll.full.pdb` and reloaded everything; this time I could view the functions names in the jvm modules displayed properly in the debugger console when stepping, but could no longer follow its excecution from the source code view. Again this is expected since public symbols contain function names and entry point addresses but not source file and line number info. So it seems that contrary to what I suggested in my previous comment, it *is* important that the `.pdb` file from where the debugger is expected to load symbols from is the same name as was provided to the linker. Now the reason why I initially thought it didn't matter is because `WinDbg` automatically caches pdb files that it successfully loaded under `C:\ProgramData\dbg\sym` and reload them from there even if the original file no longer exist. So if you load the symbols once, then rename the file and start again, you may be misled into thinking that it successfully loaded the symbols from the renamed file while it in fact did so from its cache. Hope this helps, and sorry for the potential misleading info earlier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2722436351 From mikael at openjdk.org Thu Mar 13 19:23:03 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 13 Mar 2025 19:23:03 GMT Subject: RFR: 8351603: Change to GCC 14.2.0 for building on Linux at Oracle Message-ID: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com> Background: Oracle is updating the version of GCC for building the JDK on Linux to 14.2.0. This change updates the versions of the components used for the (Linux) devkit. Newer versions of ccache use cmake for the build, so some of the logic in `make/devkit/Tools.gmk` had to be updated to support cmake based components. This change also fixes JDK-8344272 (gcc devkit doesn't have lto-plugin where needed). Testing: Manual builds, tier1-5 + additional func & performance testing. ------------- Commit messages: - Update doc/building.{md,html} - Add missing liblto_plugin.so link - Change to GCC 14.2.0 for building on Linux at Oracle Changes: https://git.openjdk.org/jdk/pull/23975/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23975&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351603 Stats: 40 lines in 3 files changed: 30 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/23975.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23975/head:pull/23975 PR: https://git.openjdk.org/jdk/pull/23975 From prr at openjdk.org Thu Mar 13 19:54:57 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 13 Mar 2025 19:54:57 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 17:30:33 GMT, Harshitha Onkar wrote: >> Upgraded Libpng to v1.6.47 > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > header update I was surprised by how many changes there are. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24021#pullrequestreview-2683217837 From prr at openjdk.org Thu Mar 13 20:02:53 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 13 Mar 2025 20:02:53 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 13:06:38 GMT, Matthias Baesken wrote: >> 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. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove AIX special handling from endian.h Looks right to me, but I will do a test build. ------------- PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2683234993 From mikael at openjdk.org Thu Mar 13 22:55:33 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 13 Mar 2025 22:55:33 GMT Subject: RFR: 8351603: Change to GCC 14.2.0 for building on Linux at Oracle [v2] In-Reply-To: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com> References: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com> Message-ID: > Background: > > Oracle is updating the version of GCC for building the JDK on Linux to 14.2.0. > > This change updates the versions of the components used for the (Linux) devkit. Newer versions of ccache use cmake for the build, so some of the logic in `make/devkit/Tools.gmk` had to be updated to support cmake based components. This change also fixes JDK-8344272 (gcc devkit doesn't have lto-plugin where needed). > > Testing: > > Manual builds, tier1-5 + additional func & performance testing. Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: Update jib-profiles.js ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23975/files - new: https://git.openjdk.org/jdk/pull/23975/files/d70f4a8c..ac2b44db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23975&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23975&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23975.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23975/head:pull/23975 PR: https://git.openjdk.org/jdk/pull/23975 From serb at openjdk.org Fri Mar 14 02:05:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 14 Mar 2025 02:05:52 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 15:45:12 GMT, Harshitha Onkar wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> header update > > make/modules/java.desktop/lib/ClientLibraries.gmk line 249: > >> 247: DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \ >> 248: DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \ >> 249: DISABLED_WARNINGS_clang_png.c := unused-function, \ > > This warning was disabled to fix the following build issue on linux and macOS. > > > open/src/java.desktop/share/native/libsplashscreen/libpng/png.c:1558:1: error: 'png_icc_profile_error' defined but not used [-Werror=unused-function] > [2025-03-12T23:57:44,575Z] 1558 | png_icc_profile_error(png_const_structrp png_ptr, png_const_charp name, > [2025-03-12T23:57:44,575Z] | ^~~~~~~~~~~~~~~~~~~~~ Might this be a bug in PNG? All usages of this function are now guarded by "PNG_READ_iCCP_SUPPORTED"? It would be useful to report this upstream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24021#discussion_r1994558215 From mbaesken at openjdk.org Fri Mar 14 08:34:00 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 14 Mar 2025 08:34:00 GMT Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings [v5] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 17:41:28 GMT, Kevin Walls wrote: > Yes seems likely the same history for libverify, so should be good to do the same update there. I created https://bugs.openjdk.org/browse/JDK-8352015 . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2723988627 From mbaesken at openjdk.org Fri Mar 14 10:11:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 14 Mar 2025 10:11:41 GMT Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings Message-ID: We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided. This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) , ------------- Commit messages: - JDK-8351821 Changes: https://git.openjdk.org/jdk/pull/24052/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24052&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351821 Stats: 8 lines in 2 files changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24052/head:pull/24052 PR: https://git.openjdk.org/jdk/pull/24052 From mbaesken at openjdk.org Fri Mar 14 10:58:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 14 Mar 2025 10:58:52 GMT Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken wrote: > We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided. > This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) , In case someone has a good/better idea what to do with the ignored returned value of `jmm_interface->GetOptionalSupport(....)` (throwing an exception? printing out something?) we can do this of course too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24052#issuecomment-2724321246 From mbaesken at openjdk.org Fri Mar 14 11:20:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 14 Mar 2025 11:20:52 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings Message-ID: On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. ------------- Commit messages: - JDK-8352015 Changes: https://git.openjdk.org/jdk/pull/24054/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24054&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352015 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24054/head:pull/24054 PR: https://git.openjdk.org/jdk/pull/24054 From mbaesken at openjdk.org Fri Mar 14 11:20:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 14 Mar 2025 11:20:52 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote: > On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. > The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. Example lib sizes in jdk head opt build on Linux x86_64 with gcc 13.2.0 are 68K without the patch and 72K with the patch, so fortunately no large size increase is seen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724370568 From ihse at openjdk.org Fri Mar 14 11:36:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 11:36:58 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote: > On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. > The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. What testing have you run? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724411872 From ihse at openjdk.org Fri Mar 14 11:38:03 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 11:38:03 GMT Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings In-Reply-To: References: Message-ID: <1XhEwT6egNq_EkiR6p2wq1qGkDXOLa-A4jt_EH_ZHUo=.4a490d5b-7f3f-48d2-b8ab-5bc335c37f7d@github.com> On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken wrote: > We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided. > This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) , Build changes look good to me. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24052#pullrequestreview-2685242504 From ihse at openjdk.org Fri Mar 14 11:39:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 11:39:58 GMT Subject: RFR: 8351603: Change to GCC 14.2.0 for building on Linux at Oracle [v2] In-Reply-To: References: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com> Message-ID: On Thu, 13 Mar 2025 22:55:33 GMT, Mikael Vidstedt wrote: >> Background: >> >> Oracle is updating the version of GCC for building the JDK on Linux to 14.2.0. >> >> This change updates the versions of the components used for the (Linux) devkit. Newer versions of ccache use cmake for the build, so some of the logic in `make/devkit/Tools.gmk` had to be updated to support cmake based components. This change also fixes JDK-8344272 (gcc devkit doesn't have lto-plugin where needed). >> >> Testing: >> >> Manual builds, tier1-5 + additional func & performance testing. > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Update jib-profiles.js You need to re-state the `/issue add JDK-8344272` command since Skara bots ignored it the first time around due to the PR title... (One could argue that this is a bug in Skara) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23975#issuecomment-2724418915 From ihse at openjdk.org Fri Mar 14 11:43:52 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 11:43:52 GMT Subject: RFR: 8351603: Change to GCC 14.2.0 for building on Linux at Oracle [v2] In-Reply-To: References: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com> Message-ID: On Thu, 13 Mar 2025 22:55:33 GMT, Mikael Vidstedt wrote: >> Background: >> >> Oracle is updating the version of GCC for building the JDK on Linux to 14.2.0. >> >> This change updates the versions of the components used for the (Linux) devkit. Newer versions of ccache use cmake for the build, so some of the logic in `make/devkit/Tools.gmk` had to be updated to support cmake based components. This change also fixes JDK-8344272 (gcc devkit doesn't have lto-plugin where needed). >> >> Testing: >> >> Manual builds, tier1-5 + additional func & performance testing. > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Update jib-profiles.js LGTM ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23975#pullrequestreview-2685253856 From ihse at openjdk.org Fri Mar 14 11:52:03 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 11:52:03 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests Given all of this, is there any possibility at all for --enable-linkable-runtime to handle both full and stripped pdb files, or do we need to accept that this is an inherent limitation for the linkable runtime? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2724440077 From alanb at openjdk.org Fri Mar 14 11:55:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Mar 2025 11:55:56 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote: > On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. > The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. In addition to testing, I assume this will require dig into why compile/other issue was being worked around at the time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724448874 From ihse at openjdk.org Fri Mar 14 12:05:08 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 12:05:08 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:53:33 GMT, Alan Bateman wrote: >> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. >> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. > > In addition to testing, I assume this will require dig into why compile/other issue was being worked around at the time. @AlanBateman This seems to be part of the same change which introduced "Full Debug Symbols" (FDS), and which took a conservative approach. See Erik's comment https://github.com/openjdk/jdk/pull/23966#issuecomment-2714883676. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724480497 From clanger at openjdk.org Fri Mar 14 12:34:03 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 14 Mar 2025 12:34:03 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:48:59 GMT, Magnus Ihse Bursie wrote: > Given all of this, is there any possibility at all for --enable-linkable-runtime to handle both full and stripped pdb files, or do we need to accept that this is an inherent limitation for the linkable runtime? Yes, I think there is ? I propose an alternative approach in #24057 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2724540420 From clanger at openjdk.org Fri Mar 14 12:36:34 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 14 Mar 2025 12:36:34 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public Message-ID: Alternative approach to #24012 This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. ------------- Commit messages: - JDK-8351842 Changes: https://git.openjdk.org/jdk/pull/24057/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24057&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351842 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24057/head:pull/24057 PR: https://git.openjdk.org/jdk/pull/24057 From mbaesken at openjdk.org Fri Mar 14 12:47:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 14 Mar 2025 12:47:57 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:34:08 GMT, Magnus Ihse Bursie wrote: > What testing have you run? I put it into our testing queue, this runs jtreg tier 1 - 4 and some more stuff over the weekend on all our platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724577126 From erikj at openjdk.org Fri Mar 14 12:54:58 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 14 Mar 2025 12:54:58 GMT Subject: RFR: 8351603: Change to GCC 14.2.0 for building on Linux at Oracle [v2] In-Reply-To: References: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com> Message-ID: <4mopWthdkonyi_kTCXDeiZ--39_Db7i_J6iYRGvYU40=.25b5be9b-8525-4b5b-9b31-a938ddae4e3e@github.com> On Thu, 13 Mar 2025 22:55:33 GMT, Mikael Vidstedt wrote: >> Background: >> >> Oracle is updating the version of GCC for building the JDK on Linux to 14.2.0. >> >> This change updates the versions of the components used for the (Linux) devkit. Newer versions of ccache use cmake for the build, so some of the logic in `make/devkit/Tools.gmk` had to be updated to support cmake based components. This change also fixes JDK-8344272 (gcc devkit doesn't have lto-plugin where needed). >> >> Testing: >> >> Manual builds, tier1-5 + additional func & performance testing. > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Update jib-profiles.js Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23975#pullrequestreview-2685424212 From alanb at openjdk.org Fri Mar 14 13:41:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Mar 2025 13:41:55 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer wrote: > Alternative approach to #24012 > > This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional. > > I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 226: > 224: if (Files.exists(strippedPath)) { > 225: path = strippedPath; > 226: } This is super weird to put here. I could imagine introducing a Windows specific plugin or option for jlink to help with this setup but I don't think we should rush into a change to JRTArchive to workaround this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995601023 From ihse at openjdk.org Fri Mar 14 13:57:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 13:57:51 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 13:38:51 GMT, Alan Bateman wrote: >> Alternative approach to #24012 >> >> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional. >> >> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions. > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 226: > >> 224: if (Files.exists(strippedPath)) { >> 225: path = strippedPath; >> 226: } > > This is super weird to put here. I could imagine introducing a Windows specific plugin or option for jlink to help with this setup but I don't think we should rush into a change to JRTArchive to workaround this. A jlink plugin sounds like a reasonable approach to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995629113 From sgehwolf at openjdk.org Fri Mar 14 14:16:55 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 14 Mar 2025 14:16:55 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer wrote: > Alternative approach to #24012 > > This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional. > > I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions. Could we change the synopsis of the bug to something like `Handle Windows specific combination of JEP 493 and --with-external-symbols-in-bundles=public`? make/Bundles.gmk line 248: > 246: %.stripped.pdb, \ > 247: $(call FindFiles, $(SYMBOLS_IMAGE_DIR)) \ > 248: ) Why filter *.stripped.pdb? Because they are useless for debugging? Then it should be mentioned as a comment. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 220: > 218: // Read from the base JDK image. > 219: Path path = BASE.resolve(m.resPath); > 220: // special case to handle stripped pdb files, e.g. --with-external-symbols-in-bundles=public Suggestion: // Windows debug symbols special case to handle stripped pdb files. For example builds // configured with --with-external-symbols-in-bundles=public src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 224: > 222: String strippedFile = m.resPath.substring(0, m.resPath.lastIndexOf(".pdb")) + ".stripped.pdb"; > 223: Path strippedPath = BASE.resolve(strippedFile); > 224: if (Files.exists(strippedPath)) { Suggestion: // With --with-external-symbols-in-bundles=public configuration, stripped // pdb files will be present in the image *in addition* to non-stripped pdb // files. Since the JMODs at build time only include stripped pdb files // (without '.stripped.' in their name), we need to do the same here so that // actually the same file content gets checked. Remember: *.stripped.pdb // files will only exist for builds configured with // --with-external-symbols-in-bundles=public configured builds. Exists check // is present to allow for regular windows builds as well. if (Files.exists(strippedPath)) { ------------- PR Review: https://git.openjdk.org/jdk/pull/24057#pullrequestreview-2685668451 PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995654219 PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995652710 PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995642566 From sgehwolf at openjdk.org Fri Mar 14 14:26:58 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 14 Mar 2025 14:26:58 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: <1DzJd8WRI4XgKwy02u0IzFFJzBROdOmNSHczFVVsFmA=.f8fc3b6a-0dab-4ed6-a9b8-558efe8c0b86@github.com> On Fri, 14 Mar 2025 12:31:22 GMT, Christoph Langer wrote: > Given all of this, is there any possibility at all for --enable-linkable-runtime to handle both full and stripped pdb files, or do we need to accept that this is an inherent limitation for the linkable runtime? I see a couple of options: 1. Do the same in JMODs that what is done in the image (*.pdb files are full, *.stripped.pdb are, well stripped). I.e. include them both. The problem should go away. I guess that's not desired for some reason? 2. @RealCLanger work-around for a work-around :) Cannot say, this is a nice solution. 3. Don't do the full *.pdb copy over stripped *.pdb files when building with `--with-external-symbols-in-bundles=public` and cater for the debugging case by providing a symbols bundle which has *.pdb (full) and *.stripped.pdb and copy them over the image. None of them seem ideal. My preference would be (3), but YMMV. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2724864698 From sgehwolf at openjdk.org Fri Mar 14 14:58:53 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 14 Mar 2025 14:58:53 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 13:55:26 GMT, Magnus Ihse Bursie wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 226: >> >>> 224: if (Files.exists(strippedPath)) { >>> 225: path = strippedPath; >>> 226: } >> >> This is super weird to put here. I could imagine introducing a Windows specific plugin or option for jlink to help with this setup but I don't think we should rush into a change to JRTArchive to workaround this. > > A jlink plugin sounds like a reasonable approach to me. I don't see how a jlink plugin could help with this. The plugin-pipeline runs after the archive resources have been processed (i.e. the latter feed into the former). If archive processing fails you won't get to plugin processing. With that said, I agree with Alan, this isn't a good place to deal with this. We'd have two special cases - 1) in the build system that copies over full pdb files 2) here in jlink to deal with the result of (1). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995732524 From jkern at openjdk.org Fri Mar 14 15:47:25 2025 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 14 Mar 2025 15:47:25 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher Message-ID: After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. Now with this change we can enable the statically linked launcher target again. There are 3 things to do. 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. ------------- Commit messages: - JDK-8352064 Changes: https://git.openjdk.org/jdk/pull/24062/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352064 Stats: 66 lines in 5 files changed: 60 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24062.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062 PR: https://git.openjdk.org/jdk/pull/24062 From ihse at openjdk.org Fri Mar 14 16:09:02 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 16:09:02 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure Message-ID: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated. ------------- Commit messages: - 8352044: Add --with-import-jvms to configure Changes: https://git.openjdk.org/jdk/pull/24063/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24063&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352044 Stats: 79 lines in 4 files changed: 70 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24063/head:pull/24063 PR: https://git.openjdk.org/jdk/pull/24063 From shade at openjdk.org Fri Mar 14 16:34:58 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 14 Mar 2025 16:34:58 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> Message-ID: <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com> On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote: > We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated. This change copies `libjvm.so` _and_ sibling `.jsa` files, right? If so, then one thing is missing: regenerating CDS archives that have opinions on `modules` filesizes/dates for fingerprinting their CDS archives. My frankensteining scripts do that by invoking new JVM explicitly with `-Xshare:dump`. But build system should already know how to do that, as it does it at the end of the build. ------------- PR Review: https://git.openjdk.org/jdk/pull/24063#pullrequestreview-2686128808 From erikj at openjdk.org Fri Mar 14 17:38:58 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 14 Mar 2025 17:38:58 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern wrote: > After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. > > Now with this change we can enable the statically linked launcher target again. > There are 3 things to do. > 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. > 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. > 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. make/StaticLibs.gmk line 116: > 114: # DEPS := $(STATIC_LIB_FILE), \ > 115: # OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \ > 116: # COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \ The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling: Suggestion: # COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \ You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1996001131 From honkar at openjdk.org Fri Mar 14 17:40:08 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 14 Mar 2025 17:40:08 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3] In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 02:02:58 GMT, Sergey Bylokhov wrote: >> make/modules/java.desktop/lib/ClientLibraries.gmk line 249: >> >>> 247: DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \ >>> 248: DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \ >>> 249: DISABLED_WARNINGS_clang_png.c := unused-function, \ >> >> This warning was disabled to fix the following build issue on linux and macOS. >> >> >> open/src/java.desktop/share/native/libsplashscreen/libpng/png.c:1558:1: error: 'png_icc_profile_error' defined but not used [-Werror=unused-function] >> [2025-03-12T23:57:44,575Z] 1558 | png_icc_profile_error(png_const_structrp png_ptr, png_const_charp name, >> [2025-03-12T23:57:44,575Z] | ^~~~~~~~~~~~~~~~~~~~~ > > Might this be a bug in PNG? All usages of this function are now guarded by "PNG_READ_iCCP_SUPPORTED"? It would be useful to report this upstream. In libconfig.h Ln#120 the undef is commented out - `/*#undef PNG_READ_iCCP_SUPPORTED*/` but I don't see it defined. @prrace do we define it in libconfig.h and remove the warning from disabled section in ClientLibraries.gmk? In Updating.txt , I see a note on libconfig.h, it is heavily modified for JDK and a define stmt can be added on need basis. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24021#discussion_r1996000410 From ihse at openjdk.org Fri Mar 14 18:35:12 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 14 Mar 2025 18:35:12 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com> Message-ID: On Fri, 14 Mar 2025 16:32:39 GMT, Aleksey Shipilev wrote: > This change copies `libjvm.so` _and_ sibling `.jsa` files, right? No, it doesn't -- only libjvm.so. .jsa files complicate the situation. Hm. Maybe we should point to an import JVM directory, and copy it with all its files, and not just try to single out the libjvm.so. That will allow imported JVMs to tag along any kind of files they want. > Try to import a JVM and do `java -Xshare:on Hello`? The problem is that we can't really count on -Xshare being supported on an imported JVM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2725393724 PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2725396677 From shade at openjdk.org Fri Mar 14 18:35:13 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 14 Mar 2025 18:35:13 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com> Message-ID: On Fri, 14 Mar 2025 17:57:31 GMT, Magnus Ihse Bursie wrote: > No, it doesn't -- only libjvm.so. .jsa files complicate the situation. Hm. Aha. Importing CDS archives without regenerating them is futile, IIRC: they would never load properly, CDS would get disabled, and we would just carry dead weight. > Maybe we should point to an import JVM directory, and copy it with all its files, and not just try to single out the libjvm.so. That will allow imported JVMs to tag along any kind of files they want. Yes. There are also debuginfo files that you certainly want. > The problem is that we can't really count on -Xshare being supported on an imported JVM. This is suggestion for testing CDS support. We don't need to do `-Xshare:on` tests from a build system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2725450392 From iklam at openjdk.org Fri Mar 14 20:19:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 14 Mar 2025 20:19:12 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java Message-ID: I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: make test JTREG=AOT_JDK=true \ TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` ------------- Commit messages: - 8352084: Add more test code in TestSetupAOT.java Changes: https://git.openjdk.org/jdk/pull/24067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352084 Stats: 172 lines in 5 files changed: 158 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/24067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24067/head:pull/24067 PR: https://git.openjdk.org/jdk/pull/24067 From kevinw at openjdk.org Fri Mar 14 20:58:51 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 14 Mar 2025 20:58:51 GMT Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken wrote: > We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided. > This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) , We know GetOptionalSupport can't realistically fail, unless we call it with a bad pointer (we don't). This location is called once only on startup. We have not checked the return value since introduced in jdk5... So can't really object to not saving that value in a temp that we ignore, and simplifying the Makefile a little! ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24052#pullrequestreview-2686805647 From dholmes at openjdk.org Fri Mar 14 21:01:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Mar 2025 21:01:52 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com> Message-ID: On Fri, 14 Mar 2025 17:58:50 GMT, Magnus Ihse Bursie wrote: >> This change copies `libjvm.so` _and_ sibling `.jsa` files, right? >> >> If so, then one thing is missing: regenerating CDS archives that have opinions on `modules` filesizes/dates for fingerprinting their CDS archives. My frankensteining scripts do that by invoking new JVM explicitly with `-Xshare:dump`. But build system should already know how to do that, as it does it at the end of the build. >> >> Try to import a JVM and do `java -Xshare:on Hello`? > >> Try to import a JVM and do `java -Xshare:on Hello`? > > The problem is that we can't really count on -Xshare being supported on an imported JVM. @magicus I'm trying to see the big picture here of all the changes you are proposing and I'm really not seeing it. This seems to be making it more difficult to create a JDK/JRE with multiple VMs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2725744927 From honkar at openjdk.org Fri Mar 14 21:25:53 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 14 Mar 2025 21:25:53 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3] In-Reply-To: References: Message-ID: <6ygTo-i9hMI4V4ZEXf2MACpCTEkLbes9HEIMyDQ0RYI=.7d749748-7a5f-4a74-b83e-90690f460e50@github.com> On Fri, 14 Mar 2025 02:02:58 GMT, Sergey Bylokhov wrote: >> make/modules/java.desktop/lib/ClientLibraries.gmk line 249: >> >>> 247: DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \ >>> 248: DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \ >>> 249: DISABLED_WARNINGS_clang_png.c := unused-function, \ >> >> This warning was disabled to fix the following build issue on linux and macOS. >> >> >> open/src/java.desktop/share/native/libsplashscreen/libpng/png.c:1558:1: error: 'png_icc_profile_error' defined but not used [-Werror=unused-function] >> [2025-03-12T23:57:44,575Z] 1558 | png_icc_profile_error(png_const_structrp png_ptr, png_const_charp name, >> [2025-03-12T23:57:44,575Z] | ^~~~~~~~~~~~~~~~~~~~~ > > Might this be a bug in PNG? All usages of this function are now guarded by "PNG_READ_iCCP_SUPPORTED"? It would be useful to report this upstream. @mrserb I see, what you meant is that the function `png_icc_profile_error` should be guarded with PNG_READ_iCCP_SUPPORTED instead of PNG_iCCP_SUPPORTED. Reported it to upstream - https://github.com/pnggroup/libpng/issues/668 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24021#discussion_r1996304716 From kvn at openjdk.org Fri Mar 14 23:30:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 14 Mar 2025 23:30:51 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam wrote: > I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: > > > make test JTREG=AOT_JDK=true \ > TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java > > > Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies > After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies > > I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2687063032 From lmesnik at openjdk.org Fri Mar 14 23:30:52 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 14 Mar 2025 23:30:52 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam wrote: > I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: > > > make test JTREG=AOT_JDK=true \ > TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java > > > Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies > After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies > > I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` Changes requested by lmesnik (Reviewer). make/RunTests.gmk line 738: > 736: $1_AOT_JDK_CACHE := $$($1_TEST_SUPPORT_DIR)/aot/jdk.aotcache > 737: $1_AOT_JDK_LOG := $$($1_TEST_SUPPORT_DIR)/aot/TestSetupAOT.log > 738: $1_AOT_JDK_OUTPUT_DIR := $$($1_TEST_SUPPORT_DIR)/aot Better to move it before line 735, and reuse in other definitions instead of $$($1_TEST_SUPPORT_DIR)/aot test/setup_aot/TestSetupAOT.java line 147: > 145: > 146: > 147: static void streamOps(String args[]) { Can you please add a comment with explanation of purpose of 'streamOps' method. test/setup_aot/TestSetupAOT.java line 201: > 199: String CSCC = "string" + s + "string" + c; > 200: > 201: long l = System.currentTimeMillis(); the l should be logged and allow to be defined using property. So any testing could be repeated. long l = Long.getLong("test.aot.seed", System.currentTimeMillis()); ------------- PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2687055469 PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996419066 PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996422306 PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996424173 From erikj at openjdk.org Fri Mar 14 23:46:52 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 14 Mar 2025 23:46:52 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam wrote: > I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: > > > make test JTREG=AOT_JDK=true \ > TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java > > > Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies > After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies > > I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` make/test/BuildTestSetupAOT.gmk line 62: > 60: JavacBenchApp$$FileManager.class \ > 61: JavacBenchApp$$SourceFile.class \ > 62: TestSetupAOT.class, \ Listing all class files like this is cumbersome. Perhaps we should build this into a jar file instead now that there are more classes? It should be as easy as adding `JAR := ` to the SetupJavaCompilation call above and then copy that file. Or would that interfere with the classpath requirements when using the tool? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996434862 From iklam at openjdk.org Sat Mar 15 02:08:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 15 Mar 2025 02:08:33 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v2] In-Reply-To: References: Message-ID: <1qxCBc_BDj7Gj7dcYamPqTRzvrfJXyIgUwKmdjOGjZE=.906f78f4-4675-4b6e-8fad-b3c500072526@github.com> > I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: > > > make test JTREG=AOT_JDK=true \ > TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java > > > Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies > After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies > > I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Review comments from @erikj79 and @lmesnik ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24067/files - new: https://git.openjdk.org/jdk/pull/24067/files/7c486a8b..82b2c11d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24067&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24067&range=00-01 Stats: 28 lines in 3 files changed: 7 ins; 7 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/24067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24067/head:pull/24067 PR: https://git.openjdk.org/jdk/pull/24067 From iklam at openjdk.org Sat Mar 15 02:08:34 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 15 Mar 2025 02:08:34 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v2] In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 23:21:59 GMT, Leonid Mesnik wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from @erikj79 and @lmesnik > > make/RunTests.gmk line 738: > >> 736: $1_AOT_JDK_CACHE := $$($1_TEST_SUPPORT_DIR)/aot/jdk.aotcache >> 737: $1_AOT_JDK_LOG := $$($1_TEST_SUPPORT_DIR)/aot/TestSetupAOT.log >> 738: $1_AOT_JDK_OUTPUT_DIR := $$($1_TEST_SUPPORT_DIR)/aot > > Better to move it before line 735, and reuse in other definitions instead of $$($1_TEST_SUPPORT_DIR)/aot Fixed. > test/setup_aot/TestSetupAOT.java line 147: > >> 145: >> 146: >> 147: static void streamOps(String args[]) { > > Can you please add a comment with explanation of purpose of 'streamOps' method. I renamed the method to `invokedynamicTests()` and added comments. > test/setup_aot/TestSetupAOT.java line 201: > >> 199: String CSCC = "string" + s + "string" + c; >> 200: >> 201: long l = System.currentTimeMillis(); > > the l should be logged and allow to be defined using property. > So any testing could be repeated. > long l = Long.getLong("test.aot.seed", System.currentTimeMillis()); I changed it to not depend on system time. Now the program should be deterministic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996506289 PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996506299 PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996506308 From iklam at openjdk.org Sat Mar 15 02:08:34 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 15 Mar 2025 02:08:34 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v2] In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 23:43:53 GMT, Erik Joelsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from @erikj79 and @lmesnik > > make/test/BuildTestSetupAOT.gmk line 62: > >> 60: JavacBenchApp$$FileManager.class \ >> 61: JavacBenchApp$$SourceFile.class \ >> 62: TestSetupAOT.class, \ > > Listing all class files like this is cumbersome. Perhaps we should build this into a jar file instead now that there are more classes? It should be as easy as adding `JAR := ` to the SetupJavaCompilation call above and then copy that file. Or would that interfere with the classpath requirements when using the tool? I changed the output to a JAR file so there's no need to enumerate all classes. When running the tool, I need to extract the class files to `$$($1_AOT_JDK_OUTPUT_DIR)` due to the reasons described in RunTests.gmk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996506325 From lmesnik at openjdk.org Sat Mar 15 03:19:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 15 Mar 2025 03:19:58 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v2] In-Reply-To: <1qxCBc_BDj7Gj7dcYamPqTRzvrfJXyIgUwKmdjOGjZE=.906f78f4-4675-4b6e-8fad-b3c500072526@github.com> References: <1qxCBc_BDj7Gj7dcYamPqTRzvrfJXyIgUwKmdjOGjZE=.906f78f4-4675-4b6e-8fad-b3c500072526@github.com> Message-ID: On Sat, 15 Mar 2025 02:08:33 GMT, Ioi Lam wrote: >> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: >> >> >> make test JTREG=AOT_JDK=true \ >> TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java >> >> >> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies >> After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies >> >> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from @erikj79 and @lmesnik Thanks for fixing those things. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2687294741 From iklam at openjdk.org Sat Mar 15 20:36:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 15 Mar 2025 20:36:09 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v3] In-Reply-To: References: Message-ID: > I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: > > > make test JTREG=AOT_JDK=true \ > TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java > > > Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies > After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies > > I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed windows path problem ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24067/files - new: https://git.openjdk.org/jdk/pull/24067/files/82b2c11d..70291772 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24067&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24067&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24067/head:pull/24067 PR: https://git.openjdk.org/jdk/pull/24067 From mbaesken at openjdk.org Sun Mar 16 13:07:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Sun, 16 Mar 2025 13:07:56 GMT Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken wrote: > We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided. > This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) , Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24052#issuecomment-2727387281 From mbaesken at openjdk.org Sun Mar 16 13:07:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Sun, 16 Mar 2025 13:07:56 GMT Subject: Integrated: 8351821: VMManagementImpl.c avoid switching off warnings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken wrote: > We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided. > This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) , This pull request has now been integrated. Changeset: 06289f3d Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/06289f3d90577d220de5509a3892f7ed260c24b9 Stats: 8 lines in 2 files changed: 0 ins; 6 del; 2 mod 8351821: VMManagementImpl.c avoid switching off warnings Reviewed-by: ihse, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/24052 From mbaesken at openjdk.org Sun Mar 16 13:26:51 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Sun, 16 Mar 2025 13:26:51 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 12:45:23 GMT, Matthias Baesken wrote: > > What testing have you run? > > I put it into our testing queue, this runs jtreg tier 1 - 4 and some more stuff over the weekend on all our platforms. No issues were seen with the patch in the mentioned tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2727422791 From dholmes at openjdk.org Mon Mar 17 05:39:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 17 Mar 2025 05:39:02 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v2] In-Reply-To: References: Message-ID: On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev 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 Apologies for the silence but I was out-of-action for several days and am still trying to catch up. Obviously different JEPs have modeled things differently and there is no one-right-way. A lot of follow-up tasks have been identified and no doubt there will be even more after that. I personally would have liked to see more of the known tasks counted as part of the JEP. Hopefully a bunch of them may be ready by the time the JEP is ready anyway. Hitting the Approve button to show "general consensus". ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2689161146 From dholmes at openjdk.org Mon Mar 17 06:43:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 17 Mar 2025 06:43:58 GMT Subject: RFR: 8351322: Parameterize link option for pthreads [v2] In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> References: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> Message-ID: On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes 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? Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway. > We can then check if we can turn -lpthread into -pthread on Linux as a follow up. I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2728361931 From clanger at openjdk.org Mon Mar 17 08:17:03 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 17 Mar 2025 08:17:03 GMT Subject: RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer wrote: >> 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests I'll close this PR because something in the lines of #24057 looks more promising to me. Let's continue the discussion there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2728536261 From clanger at openjdk.org Mon Mar 17 08:17:04 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 17 Mar 2025 08:17:04 GMT Subject: Withdrawn: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 15:57:40 GMT, Christoph Langer wrote: > 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 with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24012 From clanger at openjdk.org Mon Mar 17 08:23:01 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 17 Mar 2025 08:23:01 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 14:10:30 GMT, Severin Gehwolf wrote: >> Alternative approach to #24012 >> >> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional. >> >> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions. > > make/Bundles.gmk line 248: > >> 246: %.stripped.pdb, \ >> 247: $(call FindFiles, $(SYMBOLS_IMAGE_DIR)) \ >> 248: ) > > Why filter *.stripped.pdb? Because they are useless for debugging? Then it should be mentioned as a comment. This is fixing a small issue that is independent of JEP 493. Currently the JDK/JRE bundles contain the lib.stripped.pdb files renamed to lib.pdb. The symbols bundle contains these as well but it should have the full lib.pdb files. So, by filtering out *stripped.pdb during the creation of the symbols bundle, we make sure that the full pdb files end up in the symbols bundle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1998173085 From clanger at openjdk.org Mon Mar 17 08:29:57 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 17 Mar 2025 08:29:57 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer wrote: > Alternative approach to #24012 > > This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional. > > I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions. After running this patch through our testing I can confirm that it at least solves all existing test issues and does not create regressions. I, however, admit that the added code in JRTArchive.java is quite hacky and is actually only there to solve some testing issues, not great. Can we maybe add a possibility to store two alternative SHA sums in the JMod archives, per file? Then we could add SHA sums for both, the stripped and the full pdb file and either one which is present in the current runtime would be accepted. So we'd cover the cases where the stripped pdb files are around as well as a potential case when somebody extracted the symbols archive over the runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24057#issuecomment-2728566685 From alanb at openjdk.org Mon Mar 17 09:14:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 17 Mar 2025 09:14:03 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> Message-ID: <4Ae963vByEmyd_U31MPYWErLbam0FeKgi4Sni-ApClY=.910c3fbc-1f8b-4928-aa25-7b5a2803202b@github.com> On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote: > We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated. The discussion on jdk-dev was useful but I don't think adding --with-import-jvms is the right direction. It's too fragile and loose to import from a build created somewhere else. I can relate to Aleksey's case where it might be useful to have release + debug builds in the same run-time image. Having java launcher support selecting the fastdebug libjvm, and using jlink to include/exclude the debug VM, can become part of a good story. I'm less sure that builds that want to produce server + minimal or server + zero or other combinations like this are important or compelling in 2025. In the case of minimal then it may be more useful for the build to just produce the packaged modules (JMOD) rather than an image. When targeting small/embedded environments then this is what you need as a JDK build with all modules + minimal VM doesn't really make too much sense. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2728700020 From shade at openjdk.org Mon Mar 17 09:32:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 17 Mar 2025 09:32:00 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> Message-ID: <8c-cbH6l8A21Bn4jRomHaznZkgK6GxHpgPOO359uGa4=.9ca586ec-bf21-4e84-ae96-ab8ae3c4113b@github.com> On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote: > We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated. For completeness/reference, this is my JDK frankensteining script that is used for producing builds.shipilev.net bundles: [bundle-multi-jdk.sh.txt](https://github.com/user-attachments/files/19283184/bundle-multi-jdk.sh.txt). That would be one of the workflows that new build support feature would need to help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2728766491 From jkern at openjdk.org Mon Mar 17 10:04:56 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 17 Mar 2025 10:04:56 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 17:35:02 GMT, Erik Joelsson wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > make/StaticLibs.gmk line 116: > >> 114: # DEPS := $(STATIC_LIB_FILE), \ >> 115: # OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \ >> 116: # COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \ > > The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling: > > Suggestion: > > # COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \ > > > You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`. Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998375442 From duke at openjdk.org Mon Mar 17 10:47:06 2025 From: duke at openjdk.org (snake66) Date: Mon, 17 Mar 2025 10:47:06 GMT Subject: RFR: 8351322: Parameterize link option for pthreads [v2] In-Reply-To: References: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> Message-ID: <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com> On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes wrote: >> @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? > > Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway. > >> We can then check if we can turn -lpthread into -pthread on Linux as a follow up. > > I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag. > > 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? > > (...) I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway. I'm happy to test this, if you want. Won't have time this week, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2729033496 From erikj at openjdk.org Mon Mar 17 12:56:03 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Mar 2025 12:56:03 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v3] In-Reply-To: References: Message-ID: <1DUpAZC6naigkZlpRx4410UdrSXnwei8Ypvc3FmaFKE=.fd7cab72-2602-4ea1-a530-3ec7a6aca15e@github.com> On Sat, 15 Mar 2025 20:36:09 GMT, Ioi Lam wrote: >> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: >> >> >> make test JTREG=AOT_JDK=true \ >> TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java >> >> >> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies >> After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies >> >> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed windows path problem make/RunTests.gmk line 758: > 756: $$(call ExecuteWithLog, $$($1_AOT_JDK_OUTPUT_DIR), ( \ > 757: cd $$($1_AOT_JDK_OUTPUT_DIR); \ > 758: $$(FIXPATH) $(JAR_CMD) --extract --file $(TEST_IMAGE_DIR)/setup_aot/TestSetupAOT.jar; \ The variable `JAR` already has fixpath prefixed when needed. Suggestion: $$(JAR) --extract --file $(TEST_IMAGE_DIR)/setup_aot/TestSetupAOT.jar; \ make/test/BuildTestSetupAOT.gmk line 57: > 55: # Copy to hotspot jtreg test image > 56: $(eval $(call SetupCopyFiles, COPY_SETUP_AOT, \ > 57: SRC := $(SETUP_AOT_SUPPORT), \ With just one file being copied, the SRC argument can be omitted. It will default to the directory of the first file in FILES. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1998658649 PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1998668399 From erikj at openjdk.org Mon Mar 17 13:09:02 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Mar 2025 13:09:02 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote: > On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. > The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24054#pullrequestreview-2690424664 From jkern at openjdk.org Mon Mar 17 13:13:53 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 17 Mar 2025 13:13:53 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 10:02:12 GMT, Joachim Kern wrote: >> make/StaticLibs.gmk line 116: >> >>> 114: # DEPS := $(STATIC_LIB_FILE), \ >>> 115: # OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \ >>> 116: # COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \ >> >> The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling: >> >> Suggestion: >> >> # COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \ >> >> >> You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`. > > Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too? The problem seems to be that `$(generate_export_list)` is empty and I do not know why. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998701815 From erikj at openjdk.org Mon Mar 17 13:16:52 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Mar 2025 13:16:52 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 13:11:14 GMT, Joachim Kern wrote: >> Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too? > > The problem seems to be that `$(generate_export_list)` is empty and I do not know why. Looks like this variable is misspelled (missing "S"). DEPS := $(STATIC_LIB_FILE), \ Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998708773 From sgehwolf at openjdk.org Mon Mar 17 13:49:55 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 17 Mar 2025 13:49:55 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 08:27:20 GMT, Christoph Langer wrote: > Can we maybe add a possibility to store two alternative SHA sums in the JMod archives, per file? Then we could add SHA sums for both, the stripped and the full pdb file and either one which is present in the current runtime would be accepted. So we'd cover the cases where the stripped pdb files are around as well as a potential case when somebody extracted the symbols archive over the runtime. I wonder if there would be a more generic way to solve this. We've seen similar issues with JDK image post-processing interfering with the SHA sum check. The general problem is that for some cases SHA sum checking is too strict (e.g. for signed binaries or stripped binaries - debug symbol processing). Now those use-cases aren't for everyone. So it would be ideal if we could opt-into a more lenient SHA sum checking without needing to change the JMOD archive format. The prime reason for the SHA sum check was population of modified configuration files to the linked image. `SaveJLinkArgFilesPlugin` comes to mind. How about we added a way of checking the SHA for a file from a set of values (it could be restricted to binaries and libraries only). Say, this set of SHA sums could be passed to `jlink` itself with an option, say `--sha-mappings=...`. That option could be a list of file/sha pairs or use `file:` with a mapping. Then, we could add an additional configure option to the JDK build which adds such sha mappings to `jlink` with the `--save-jlink-argfiles` option to the resulting `jlink`. For the Windows case configured with `--with-external-symbols-in-bundles=public` case this could be done at build time. The resulting `jlink` would use `--sha-mappings` as needed for `*.pdb` files only, solving this problem. For RPM builds where we face similar issues of *.so files and executables getting stripped of debug symbols way after the JDK build completes. We could add `--sha-mappings=file:$JAVA_HOME/conf/jlink_extra_mappings.txt` via `--save-jlink-argfiles` and allow for the new SHA sum in that file - again restricting this multi-mapping for binaries/libraries only. Thoughts? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24057#issuecomment-2729570316 From jkern at openjdk.org Mon Mar 17 15:03:52 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 17 Mar 2025 15:03:52 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 13:14:44 GMT, Erik Joelsson wrote: >> The problem seems to be that `$(generate_export_list)` is empty and I do not know why. > > Looks like this variable is misspelled (missing "S"). > > DEPS := $(STATIC_LIB_FILE), \ > > Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message. Ups, thank you for giving me the 'S'. But nevertheless if I make with `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998959519 From lmesnik at openjdk.org Mon Mar 17 16:29:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 17 Mar 2025 16:29:39 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v3] In-Reply-To: References: Message-ID: On Sat, 15 Mar 2025 20:36:09 GMT, Ioi Lam wrote: >> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: >> >> >> make test JTREG=AOT_JDK=true \ >> TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java >> >> >> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies >> After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies >> >> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed windows path problem Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2691173425 From iklam at openjdk.org Mon Mar 17 16:35:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 17 Mar 2025 16:35:12 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v4] In-Reply-To: References: Message-ID: > I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: > > > make test JTREG=AOT_JDK=true \ > TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java > > > Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies > After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies > > I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @erikj79 comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24067/files - new: https://git.openjdk.org/jdk/pull/24067/files/70291772..ae241b5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24067&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24067&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24067/head:pull/24067 PR: https://git.openjdk.org/jdk/pull/24067 From honkar at openjdk.org Mon Mar 17 16:54:14 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 17 Mar 2025 16:54:14 GMT Subject: RFR: JDK-8348598 : Update Libpng to 1.6.47 [v3] In-Reply-To: References: Message-ID: <4_QJjFc10KjzY7epVf_sSsh5eCbCjBdB39jLoFTE09s=.99e862b8-419d-43d2-8cbf-49a80c3be8a1@github.com> On Thu, 13 Mar 2025 19:52:12 GMT, Phil Race wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> header update > > I was surprised by how many changes there are. @prrace > I was surprised by how many changes there are. Yes, it was definitively more compared to last update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24021#issuecomment-2730214678 From honkar at openjdk.org Mon Mar 17 16:54:15 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 17 Mar 2025 16:54:15 GMT Subject: Integrated: JDK-8348598 : Update Libpng to 1.6.47 In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 00:27:46 GMT, Harshitha Onkar wrote: > Upgraded Libpng to v1.6.47 This pull request has now been integrated. Changeset: 6b82b42a Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/6b82b42a2116900b2125e03c1ffa0824d6062757 Stats: 4890 lines in 20 files changed: 1906 ins; 2195 del; 789 mod 8348598: Update Libpng to 1.6.47 Reviewed-by: azvegint, prr, erikj ------------- PR: https://git.openjdk.org/jdk/pull/24021 From erikj at openjdk.org Mon Mar 17 17:37:22 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Mar 2025 17:37:22 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v4] In-Reply-To: References: Message-ID: <_uEgF1C6bBPSqmc2zN2JKVJ1HfRI-VkwIUwnO6_UO4k=.e6bcb686-2ec1-4dd2-aabe-07845ce2fb6b@github.com> On Mon, 17 Mar 2025 16:35:12 GMT, Ioi Lam wrote: >> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: >> >> >> make test JTREG=AOT_JDK=true \ >> TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java >> >> >> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies >> After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies >> >> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @erikj79 comments Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2691495023 From iklam at openjdk.org Tue Mar 18 00:52:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 18 Mar 2025 00:52:15 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v3] In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 16:07:09 GMT, Leonid Mesnik wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed windows path problem > > Marked as reviewed by lmesnik (Reviewer). Thanks @lmesnik @erikj79 @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/24067#issuecomment-2731289843 From iklam at openjdk.org Tue Mar 18 00:52:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 18 Mar 2025 00:52:16 GMT Subject: Integrated: 8352084: Add more test code in TestSetupAOT.java In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam wrote: > I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: > > > make test JTREG=AOT_JDK=true \ > TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java > > > Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies > After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies > > I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` This pull request has now been integrated. Changeset: 38499b3f Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/38499b3fbfcd22252ddf860d42b9eb0bf6f77235 Stats: 185 lines in 5 files changed: 159 ins; 1 del; 25 mod 8352084: Add more test code in TestSetupAOT.java Reviewed-by: erikj, kvn, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/24067 From jkern at openjdk.org Tue Mar 18 10:47:07 2025 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 18 Mar 2025 10:47:07 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 15:01:10 GMT, Joachim Kern wrote: >> Looks like this variable is misspelled (missing "S"). >> >> DEPS := $(STATIC_LIB_FILE), \ >> >> Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message. > > Ups, thank you for giving me the 'S'. But nevertheless if I make with > `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list I did not get the SetupExecute function, even if I strip it down to a simple example $(eval $(call SetupExecute, generate_export_list, \ INFO := Generating export list for static libs, \ DEPS := /path/libjli.a, \ OUTPUT_FILE := /path/libjli.a.exp, \ COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | $(SORT) -u >$$@, \ )) $(java): $(STATIC_LIB_FILES) /path/libjli.a.exp I still get `gmake[3]: *** No rule to make target '/path/libjli.a.exp', needed by '/path2/java'. Stop. ` Why does make not recognize, that the rule is in my `call SetupExecute, generate_export_list,` macro? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000736109 From jwaters at openjdk.org Tue Mar 18 11:35:17 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 18 Mar 2025 11:35:17 GMT Subject: RFR: 8342869: Errors related to unused code on Windows after 8339120 in awt In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > build.log on release configuration: > > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=] > 3560 | static const UINT _VKS_ALT_MASK = 0x04; > | ^~~~~~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs] > 1361 | } SUBTABLE, *PSUBTABLE; > | ^~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs] > 1588 | } HEAD, *PHEAD; > | ^~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs] > 1595 | } ENTRY, *PENTRY; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/... Keep open please ------------- PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2732871765 From ihse at openjdk.org Tue Mar 18 11:41:13 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Mar 2025 11:41:13 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote: > On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. > The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24054#pullrequestreview-2694167632 From ihse at openjdk.org Tue Mar 18 11:47:12 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Mar 2025 11:47:12 GMT Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v4] In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 16:35:12 GMT, Ioi Lam wrote: >> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g: >> >> >> make test JTREG=AOT_JDK=true \ >> TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java >> >> >> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies >> After: the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies >> >> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*` > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @erikj79 comments make/RunTests.gmk line 757: > 755: $$(call LogWarn, AOT: Create cache configuration) \ > 756: $$(call ExecuteWithLog, $$($1_AOT_JDK_OUTPUT_DIR), ( \ > 757: cd $$($1_AOT_JDK_OUTPUT_DIR); \ @iklam I missed commenting on both this and the prior PR that introduced this function, but if you go back and modify this function again, please use `&&` instead of `;` to separate shell commands. That will chain them so that if the first one fails, the rest will not be executed. (We are setting the `-e` flag so the current code should have the same behavior, but writing `&&` makes it explicit for the reader, and is the style we have been adopting elsewhere in the build system.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r2000860852 From ihse at openjdk.org Tue Mar 18 12:12:13 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Mar 2025 12:12:13 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern wrote: > After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. > > Now with this change we can enable the statically linked launcher target again. > There are 3 things to do. > 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. > 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. > 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. make/StaticLibs.gmk line 112: > 110: $(STATIC_LIB_EXPORT_FILES): $(STATIC_LIB_FILES) > 111: $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@ > 112: #$(eval $(call SetupExecute, generate_export_list, \ I think there are multiple issues at hand here. 1) There is a current bug in SetupExecute that requires you to execute any command with redirection in a subshell, that is, you need to wrap the COMMAND in `(` ... `)`. 2) STATIC_LIB_EXPORT_FILES is not a single file, it is a list of file. So what you have written above is not a single recipe, it is a multi-file recipe template. But it's weird, it will evaluate to like: libjvm.so.exp libjava.so.exp libjli.so.exp: libjvm.so libjava.so libjli.so which makes no sense, since you do not need to have a dependency to libjava.so libjli.so for libjvm.so.exp. What you really want is to have a single rule per library that creates the corresponding exp file for that library, and which is dependent only on that library. Or, possibly, you can just concatenate the export of all libraries into a single file. It will make the final linker command line simpler, since you would only need a single `-Wl,-bE:`, but it is potentially worse for an incremental rebuild, since all native libraries need to be re-scanned for exported functions. My preferred solution would to make this explicit by creating a loop over STATIC_LIB_FILES, and doing a SetupExecute for each such lib. Then you can get it down to something like: $(foreach lib, $(STATIC_LIB_FILES), \ $(eval $(call SetupExecute, generate_export_list_$(lib), INFO := Generating export list for $(lib), \ DEPS := $(lib), \ OUTPUT_FILE := $(lib).exp, \ COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | sort -u > $(lib).exp ), \ ) \ $(eval STATIC_LIB_EXPORT_FILES += $(lib).exp) \ ) make/StaticLibs.gmk line 136: > 134: )) > 135: > 136: $(java): $(STATIC_LIB_FILES) $(if $(call isTargetOs, aix), $(STATIC_LIB_EXPORT_FILES)) This is just clunky. Leave the original line, and add: ifeq ($(call isTargetOs, aix), true) $(java): $(STATIC_LIB_EXPORT_FILES) endif ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000901430 PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000904229 From ihse at openjdk.org Tue Mar 18 12:15:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Mar 2025 12:15:07 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Tue, 18 Mar 2025 10:44:46 GMT, Joachim Kern wrote: >> Ups, thank you for giving me the 'S'. But nevertheless if I make with >> `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list > > I did not get the SetupExecute to function, even if I strip it down to a simple example > > $(eval $(call SetupExecute, generate_export_list, \ > INFO := Generating export list for static libs, \ > DEPS := /path/libjli.a, \ > OUTPUT_FILE := /path/libjli.a.exp, \ > COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | $(SORT) -u >$$@, \ > )) > > $(java): $(STATIC_LIB_FILES) /path/libjli.a.exp > > I still get > `gmake[3]: *** No rule to make target '/path/libjli.a.exp', needed by '/path2/java'. Stop. > ` > Why does make not recognize, that the rule is in my > `call SetupExecute, generate_export_list,` > macro? This is likely due to the missing subshell. There is an enhancement filed to fix this automatically but it has unfortunately not been prioritized: https://bugs.openjdk.org/browse/JDK-8233115 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000909674 From ihse at openjdk.org Tue Mar 18 12:30:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Mar 2025 12:30:11 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <4Ae963vByEmyd_U31MPYWErLbam0FeKgi4Sni-ApClY=.910c3fbc-1f8b-4928-aa25-7b5a2803202b@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <4Ae963vByEmyd_U31MPYWErLbam0FeKgi4Sni-ApClY=.910c3fbc-1f8b-4928-aa25-7b5a2803202b@github.com> Message-ID: On Mon, 17 Mar 2025 09:10:50 GMT, Alan Bateman wrote: > The discussion on jdk-dev was useful but I don't think adding --with-import-jvms is the right direction. It's too fragile and loose to import from a build created somewhere else. Why's that? It's more loose than just "importing" a jtreg jar from "somewhere else". Nor is it any more fragile than any other part of the build system. In fact, I think you seriously underestimate how fragile the *current* solution is, where we have to manage multiple hotspot builds. I've lost count on how many times we've had to solve bugs related to this. That is a very weird quirk in the build system, that has ramifications all over, and making all changes related to hotspot being much harder and riskier. Also, to quote what I just wrote in a JBS issue: This is all not really about removing any functionality. It is just about shifting the cost of doing this odd combinations to the distributors who still want to support them, instead of letting the entire JDK build ecosystem pay the price. Any distributor who wants to build a JDK with both minimal and server will still be able to do that. But since that is a niche case, it stands to reason that they must add just a tiny bit of complexity to their build scripts to achieve this. But as a result of removing this complexity from the build system in the JDK, it will allow us to unlock a lot of well-needed functionality, such as decoupling the gtest build from the hotspot build. This in turn will lead to faster builds, and the ability to use gtest for testing of native libs (outside Hotspot) in the JDK. I can't see how it is by any mean worth paying the price of missing out on this functionality, just to keep distributors from having to modify their build scripts, for a combination that I think everyone agrees are at least on its way out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733044671 From ihse at openjdk.org Tue Mar 18 12:36:06 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Mar 2025 12:36:06 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> Message-ID: <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com> On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote: > We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated. And to be absolutely clear: this PR is just about adding new functionality that was not present before. A follow-up PR for JDK-8352045 will actually remove functionality from the build system. But, and once again, let me be absolutely clear, the intention is that even after that PR, any distributor who wants to build an image with multiple JVMs will still be able to do so. The generated bits will be identical before and after JDK-8352045; the only difference is that you are going to need a "pre-build" step for each additional JVM you want to add, where the pre-build step basically consists of calling `bash configure --with-jvm-variant= && make hotspot`. If you add this simple step, you are going to get the exact same bits in the image. In theory, I could even program a make target to call `configure --with-jvm-variant= --with-conf-name=support-for- && make hotspot CONF=support-for-` but that's kind of silly, and looks like babysitting and insulting the intelligence of distributors... ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733054041 PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733057930 From mbaesken at openjdk.org Tue Mar 18 13:02:13 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Mar 2025 13:02:13 GMT Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote: > On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. > The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2733131425 From mbaesken at openjdk.org Tue Mar 18 13:02:14 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Mar 2025 13:02:14 GMT Subject: Integrated: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote: > On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed. > The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH. This pull request has now been integrated. Changeset: a37d8434 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/a37d8434ab991507bf8085ecf7816d0cd41ab584 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod 8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/jdk/pull/24054 From erikj at openjdk.org Tue Mar 18 13:07:09 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 18 Mar 2025 13:07:09 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> Message-ID: On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote: > We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated. make/modules/java.base/Copy.gmk line 128: > 126: $(foreach import_jvm, $(IMPORT_JVM_NAMES), \ > 127: $(eval $(import_jvm)_path := $(patsubst $(import_jvm):%,%,$(filter $(import_jvm):%, $(IMPORT_JVMS)))) \ > 128: $(eval $(call MakeDir, $(LIB_DST_DIR)/$(import_jvm))) \ Do you really need to call MakeDir outside of a recipe? Won't SetupCopyFiles recipes create this directory? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24063#discussion_r2000996873 From erikj at openjdk.org Tue Mar 18 13:12:08 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 18 Mar 2025 13:12:08 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> Message-ID: <2lDDKpoAYVPFPm24kwg2gjpmgAGnPz-_lh3r2UCpb2c=.776de8cb-9fb1-4549-b335-399cdb6450f3@github.com> On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote: > We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated. If we want to support CDS archives for the imported JVMs, then we would need to modify the loop in Images.gmk so that it covers them as well. I think that makes sense to do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733160930 From ihse at openjdk.org Tue Mar 18 13:15:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Mar 2025 13:15:18 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <2lDDKpoAYVPFPm24kwg2gjpmgAGnPz-_lh3r2UCpb2c=.776de8cb-9fb1-4549-b335-399cdb6450f3@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <2lDDKpoAYVPFPm24kwg2gjpmgAGnPz-_lh3r2UCpb2c=.776de8cb-9fb1-4549-b335-399cdb6450f3@github.com> Message-ID: On Tue, 18 Mar 2025 13:09:10 GMT, Erik Joelsson wrote: > If we want to support CDS archives for the imported JVMs, then we would need to modify the loop in Images.gmk so that it covers them as well. I think that makes sense to do. Yes, I agree. That, and importing the whole directory, is the two changes I have on my mental todo list for this PR. > make/modules/java.base/Copy.gmk line 128: > >> 126: $(foreach import_jvm, $(IMPORT_JVM_NAMES), \ >> 127: $(eval $(import_jvm)_path := $(patsubst $(import_jvm):%,%,$(filter $(import_jvm):%, $(IMPORT_JVMS)))) \ >> 128: $(eval $(call MakeDir, $(LIB_DST_DIR)/$(import_jvm))) \ > > Do you really need to call MakeDir outside of a recipe? Won't SetupCopyFiles recipes create this directory? I assumed it would, but it failed, and I looked at the code and found no clear evidence that it does, so I added this. It might have been some other issue, so I can double-check again, if you are certain that SetupCopyFiles should create needed directories. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733171467 PR Review Comment: https://git.openjdk.org/jdk/pull/24063#discussion_r2001014378 From erikj at openjdk.org Tue Mar 18 15:37:09 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 18 Mar 2025 15:37:09 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <2lDDKpoAYVPFPm24kwg2gjpmgAGnPz-_lh3r2UCpb2c=.776de8cb-9fb1-4549-b335-399cdb6450f3@github.com> Message-ID: On Tue, 18 Mar 2025 13:12:16 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/Copy.gmk line 128: >> >>> 126: $(foreach import_jvm, $(IMPORT_JVM_NAMES), \ >>> 127: $(eval $(import_jvm)_path := $(patsubst $(import_jvm):%,%,$(filter $(import_jvm):%, $(IMPORT_JVMS)))) \ >>> 128: $(eval $(call MakeDir, $(LIB_DST_DIR)/$(import_jvm))) \ >> >> Do you really need to call MakeDir outside of a recipe? Won't SetupCopyFiles recipes create this directory? > > I assumed it would, but it failed, and I looked at the code and found no clear evidence that it does, so I added this. It might have been some other issue, so I can double-check again, if you are certain that SetupCopyFiles should create needed directories. SetupCopyFiles uses `install-file` by default and that macro calls `MakeTargetDir`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24063#discussion_r2001341907 From jkern at openjdk.org Tue Mar 18 16:18:52 2025 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 18 Mar 2025 16:18:52 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v2] In-Reply-To: References: Message-ID: > After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. > > Now with this change we can enable the statically linked launcher target again. > There are 3 things to do. > 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. > 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. > 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: following Magnus proposals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24062/files - new: https://git.openjdk.org/jdk/pull/24062/files/48668be6..6e76f114 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=00-01 Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/24062.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062 PR: https://git.openjdk.org/jdk/pull/24062 From jkern at openjdk.org Tue Mar 18 16:21:14 2025 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 18 Mar 2025 16:21:14 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern wrote: > After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. > > Now with this change we can enable the statically linked launcher target again. > There are 3 things to do. > 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. > 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. > 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. I applied all of magnus proposals, but I still get `gmake[3]: *** No rule to make target '/static_libs/jdk/build/aix-ppc64-server-fastdebug/support/native/java.base/libverify/static/libverify.a.exp', needed by '/static_libs/jdk/build/aix-ppc64-server-fastdebug/support/static-native/launcher/java'. Stop.` ------------- PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2733873645 From alanb at openjdk.org Wed Mar 19 09:14:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Mar 2025 09:14:07 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com> Message-ID: <_cfhL_4tqzKarT8jOhX7HtQZM9C_bsJcXFTgQxYn45w=.fcbf73ff-8c5d-4050-9ee2-9bc18c9d461b@github.com> On Tue, 18 Mar 2025 12:31:27 GMT, Magnus Ihse Bursie wrote: > And to be absolutely clear: this PR is just about adding new functionality that was not present before. Sure but I think it's also an attractive nuisance. The VM is very tightly coupled to java.base and a few other core modules. I don't think the build should be supporting grabbing libjvm from another build or another location. Point taken that tools to build and test the JDK need to come from somewhere but it's not as tightly coupled as we have with the proposal here. For the folks targeting embedded/small environments then I think the right thing is to publish the packaged modules (JMOD files) for the target platform and then use `jlink` to create the run-image with the right VM + small set of modules that are appropriate for the target environment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2735829450 From erikj at openjdk.org Wed Mar 19 12:48:08 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 19 Mar 2025 12:48:08 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: <_cfhL_4tqzKarT8jOhX7HtQZM9C_bsJcXFTgQxYn45w=.fcbf73ff-8c5d-4050-9ee2-9bc18c9d461b@github.com> References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com> <_cfhL_4tqzKarT8jOhX7HtQZM9C_bsJcXFTgQxYn45w=.fcbf73ff-8c5d-4050-9ee2-9bc18c9d461b@github.com> Message-ID: On Wed, 19 Mar 2025 09:11:05 GMT, Alan Bateman wrote: > For the folks targeting embedded/small environments then I think the right thing is to publish the packaged modules (JMOD files) for the target platform and then use `jlink` to create the run-image with the right VM + small set of modules that are appropriate for the target environment. Just to make sure I'm understanding you correctly. Are you proposing that instead of building a single JDK distribution with multiple JVMs, they would build a separate JDK for each alternative JVM configuration and publish java.base.jmod from each of them for end users to pick from when generating their run-images? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2736507794 From qpzhang at openjdk.org Wed Mar 19 14:48:45 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Wed, 19 Mar 2025 14:48:45 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files Message-ID: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. This PR does: 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. ------------- Commit messages: - STATIC_LIB_CFLAGS in Flags.gmk should be updated to -DSTATIC_BUILD=1 too - precompiled.hpp.gch should be compiled with EXTRA_CXXFLAGS - 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files Changes: https://git.openjdk.org/jdk/pull/24115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352284 Stats: 8 lines in 5 files changed: 2 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24115/head:pull/24115 PR: https://git.openjdk.org/jdk/pull/24115 From erikj at openjdk.org Wed Mar 19 18:31:08 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 19 Mar 2025 18:31:08 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files In-Reply-To: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Wed, 19 Mar 2025 14:43:28 GMT, Patrick Zhang wrote: > Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. > > The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. > > This PR does: > 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. > 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. > 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. > > Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. I think I understand what you are trying to achieve, but this isn't the right solution. The `EXTRA_[C|CXX]FLAGS` variables are not meant to be parameters to SetupNativeCompilation. In flags.m4 you can see that the intent is to not even export `EXTRA_[C|CXX]FLAGS` from spec.gmk: # FIXME: For compatibility, export this as EXTRA_CFLAGS for now. EXTRA_CFLAGS="$MACHINE_FLAG $USER_CFLAGS" EXTRA_CXXFLAGS="$MACHINE_FLAG $USER_CXXFLAGS" EXTRA_LDFLAGS="$MACHINE_FLAG $USER_LDFLAGS" EXTRA_ASFLAGS="$USER_ASFLAGS" We don't want library/executable specific makefiles to have to worry about the extra flags supplied by the user. Those should be handled in lower layers. Given that, I agree with the change in JvmFlags.gmk. We shouldn't add `$(EXTRA_CFLAGS)` there. If we wanted those added, it should be done in configure, where `EXTRA_CXXFLAGS` are added, but not doing that is your whole goal here. Wouldn't just the change in JvmFlags.gmk be enough to solve your issue? ------------- PR Review: https://git.openjdk.org/jdk/pull/24115#pullrequestreview-2699645789 From qpzhang at openjdk.org Thu Mar 20 01:13:25 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Thu, 20 Mar 2025 01:13:25 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Wed, 19 Mar 2025 18:28:50 GMT, Erik Joelsson wrote: > The `EXTRA_[C|CXX]FLAGS` variables are not meant to be parameters to SetupNativeCompilation Actually, the content of EXTRA_[C|CXX]FLAGS is hidden (and mixed together) inside the `JVM_CFLAGS` and get passed to as a parameter to `SetupNativeCompilation` eventually. The diff is whether we want to pass them implicitly (**base**) or explicitly (**patch**). The call sequence is: 1. Set up **JVM_CFLAGS** and append **EXTRA_CXXFLAGS** (make/autoconf/flags-cflags.m4#893) -> 2. Update **JVM_CFLAGS** and append **EXTRA_CFLAGS** (make/hotspot/lib/JvmFlags.gmk#L89) -> 3. Build libjvm -> 4. SetupJdkLibrary (pass **JVM_CFLAGS** as a parameter called **CFLAGS**, make/hotspot/lib/CompileJvm.gmk#L172) -> 5. SetupJdkNativeCompilation (make/common/JdkNativeCompilation.gmk#L477) -> 6. SetupNativeCompilation (make/common/JdkNativeCompilation.gmk#L456) -> 7. SetupCompilerFlags (set CXXFLAGS to **JVM_CFLAGS** now, make/common/NativeCompilation.gmk#L159, make/common/native/Flags.gmk#L131); CreateCompiledNativeFile (BASE_CXXFLAGS contains **JVM_CFLAGS** now, make/common/NativeCompilation.gmk#L179) -> 8. Compile C++ with BASE_CXXFLAGS that contains **JVM_CFLAGS** (make/common/native/CompileFile.gmk#L162) > Wouldn't just the change in JvmFlags.gmk be enough to solve your issue? No, it seems not doable. As mentioned above in the step 1 and 2, **JVM_CFLAGS** contains both EXTRA_CXXFLAGS and EXTRA_CFLAGS at that time, when calling SetupNativeCompilation, there is no information left about which flags were from EXTRA_[C|CXX]FLAGS and we are unable to do filter-out for C vs C++ files using corresponding flags. So, it is a dilemma, if we want to keep the parameters list of SetupNativeCompilation clean (untouched) we would have EXTRA_[C|CXX]FLAGS mixed together for compiling C and C++ files. Any other idea here please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2738738973 From qpzhang at openjdk.org Thu Mar 20 04:58:06 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Thu, 20 Mar 2025 04:58:06 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Thu, 20 Mar 2025 01:10:19 GMT, Patrick Zhang wrote: > Wouldn't just the change in JvmFlags.gmk be enough to solve your issue? Forgot to mention, one of my initial try-outs (hacking) was: Remove `$(EXTRA_CFLAGS)` from `JVM_CFLAGS`, based on an assumption that all source files under `$(TOPDIR)/src/hotspot` are (according to `hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.d`) and will be C++ files only which has `$(EXTRA_CXXFLAGS)` and does **not** need `$(EXTRA_CFLAGS)` . This practically solved the issue I observed, however I don't think it was an elegant solution. Is this more acceptable than adding parameters to `SetupNativeCompilation` (actually the call to `SetupJdkLibrary)? diff --git a/make/hotspot/lib/JvmFlags.gmk b/make/hotspot/lib/JvmFlags.gmk index 97538da74c7..57b632ee532 100644 --- a/make/hotspot/lib/JvmFlags.gmk +++ b/make/hotspot/lib/JvmFlags.gmk @@ -91,7 +91,6 @@ JVM_CFLAGS += \ $(JVM_CFLAGS_TARGET_DEFINES) \ $(JVM_CFLAGS_FEATURES) \ $(JVM_CFLAGS_INCLUDES) \ - $(EXTRA_CFLAGS) \ # ------------- PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2739150006 From syan at openjdk.org Thu Mar 20 07:01:40 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 20 Mar 2025 07:01:40 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang Message-ID: Hi all, There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out Thu Mar 20 02:46:13 PM CST 2025 GNU ld (GNU Binutils) 2.43.50.20240909 File: a.out Size: 792 Blocks: 8 IO Block: 4096 regular file Device: 10303h/66307d Inode: 2355308 Links: 1 Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) Access: 2025-03-20 14:46:13.682967228 +0800 Modify: 2025-03-20 14:46:13.682967228 +0800 Change: 2025-03-20 14:46:13.682967228 +0800 Birth: 2025-03-20 14:46:13.674966977 +0800 -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out a.out: data ------------- Commit messages: - 8352481: Extra a.out generated after configure with clang Changes: https://git.openjdk.org/jdk/pull/24125/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352481 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24125/head:pull/24125 PR: https://git.openjdk.org/jdk/pull/24125 From alanb at openjdk.org Thu Mar 20 08:35:06 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 20 Mar 2025 08:35:06 GMT Subject: RFR: 8352044: Add --with-import-jvms to configure In-Reply-To: References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com> <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com> <_cfhL_4tqzKarT8jOhX7HtQZM9C_bsJcXFTgQxYn45w=.fcbf73ff-8c5d-4050-9ee2-9bc18c9d461b@github.com> Message-ID: On Wed, 19 Mar 2025 12:45:23 GMT, Erik Joelsson wrote: > Just to make sure I'm understanding you correctly. Are you proposing that instead of building a single JDK distribution with multiple JVMs, they would build a separate JDK for each alternative JVM configuration and publish java.base.jmod from each of them for end users to pick from when generating their run-images? I think there is a compelling case for having a release + fastdebug build of a server libjvm in the same run-time image. I'm dubious about server + minimal in the same run-time image, it's just too weird unless users of minimal VM are also running with `--limit-modules` to use a reduced set of modules before running `jlink` to create the target run-time image for the small environment. For embedded environments then it could be compelling to have the the packaged modules (JMOD files, and not just java.base) published for several OS/architectures. There's a connection to cross building here. Once you have the packaged modules then someone could run `jlink` (on a main-stream platform) to produce the run-time containing the small set of modules that are appropriate for the target environment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2739578163 From ihse at openjdk.org Thu Mar 20 12:41:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 12:41:16 GMT Subject: RFR: 8351322: Parameterize link option for pthreads [v2] In-Reply-To: <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com> References: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com> Message-ID: On Mon, 17 Mar 2025 10:44:30 GMT, snake66 wrote: >>> 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? >> >> Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway. >> >>> We can then check if we can turn -lpthread into -pthread on Linux as a follow up. >> >> I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag. > >> > 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? >> >> (...) I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway. > > I'm happy to test this, if you want. Won't have time this week, though. @snake66 No need, I'm already on it: https://github.com/openjdk/jdk/pull/24130 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2740320801 From ihse at openjdk.org Thu Mar 20 12:41:17 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 12:41:17 GMT Subject: RFR: 8351322: Parameterize link option for pthreads [v2] In-Reply-To: References: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> Message-ID: On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes wrote: >> @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? > > Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway. > >> We can then check if we can turn -lpthread into -pthread on Linux as a follow up. > > I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag. @dholmes-ora > I have a vague recollection that at one time -pthread set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag. Is there any gain then in changing away from `-lpthread`? That is clearly defined, link with libpthread, with no side effects. "If it ain't broke..." ------------- PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2740323348 From ihse at openjdk.org Thu Mar 20 13:20:48 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 13:20:48 GMT Subject: RFR: 8352510: Don't reset LCMS_CFLAGS Message-ID: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250. The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up. ------------- Commit messages: - 8352510: Don't reset LCMS_CFLAGS Changes: https://git.openjdk.org/jdk/pull/24131/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24131&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352510 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24131.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24131/head:pull/24131 PR: https://git.openjdk.org/jdk/pull/24131 From mbaesken at openjdk.org Thu Mar 20 13:22:08 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Mar 2025 13:22:08 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 20:00:33 GMT, Phil Race wrote: > Looks right to me, but I will do a test build. Was the test build successful ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2740436693 From jkern at openjdk.org Thu Mar 20 14:30:58 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 20 Mar 2025 14:30:58 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v3] In-Reply-To: References: Message-ID: > After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. > > Now with this change we can enable the statically linked launcher target again. > There are 3 things to do. > 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. > 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. > 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: added needed include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24062/files - new: https://git.openjdk.org/jdk/pull/24062/files/6e76f114..200c36f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24062.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062 PR: https://git.openjdk.org/jdk/pull/24062 From jkern at openjdk.org Thu Mar 20 14:38:09 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 20 Mar 2025 14:38:09 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v3] In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > added needed include I found the problem: `include Execute.gmk` was missing. Now in the same directory beside the three files e.g. libjli.a BUILD_LIBJLI_run_ar.cmdline BUILD_LIBJLI_run_ar I also get libjli.a.exp _generate_export_list_libjli.a_exec.cmdline _generate_export_list_libjli.a_exec So I think point 3 of the PR description is solved, although I find the name `_generate_export_list_libjli.a_exec` a little bit to long. The next point to work on is No. 2 of the PR description (3 `dladdr()` implementations spread over the code). Who can help me out with a review and a tip in which direction I should go? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2740683211 From ihse at openjdk.org Thu Mar 20 15:24:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 15:24:18 GMT Subject: RFR: 8352506: Simplify make/test/JtregNativeHotspot.gmk Message-ID: The file to setup special arguments to native JTReg Hotspot tests is needlessly complicated. With some generalisation, we can make it much simpler. ------------- Commit messages: - 8352506: Simplify make/test/JtregNativeHotspot.gmk Changes: https://git.openjdk.org/jdk/pull/24130/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24130&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352506 Stats: 1527 lines in 2 files changed: 35 ins; 1447 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/24130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24130/head:pull/24130 PR: https://git.openjdk.org/jdk/pull/24130 From ihse at openjdk.org Thu Mar 20 15:24:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 15:24:18 GMT Subject: RFR: 8352506: Simplify make/test/JtregNativeHotspot.gmk In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 12:32:53 GMT, Magnus Ihse Bursie wrote: > The file to setup special arguments to native JTReg Hotspot tests is needlessly complicated. With some generalisation, we can make it much simpler. This has passed hotspot testing for tier1-3 in the Oracle CI system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24130#issuecomment-2740830722 From erikj at openjdk.org Thu Mar 20 16:02:08 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Mar 2025 16:02:08 GMT Subject: RFR: 8352510: Don't reset LCMS_CFLAGS In-Reply-To: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> References: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> Message-ID: <4Kz-WIZcYbj0VGM-RfiAqjQyraz5wXESStJ6cDFZT44=.72b46bfe-56ba-4900-ac52-d7336c6c406e@github.com> On Thu, 20 Mar 2025 13:15:01 GMT, Magnus Ihse Bursie wrote: > In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250. > > The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24131#pullrequestreview-2703307744 From erikj at openjdk.org Thu Mar 20 16:52:08 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Mar 2025 16:52:08 GMT Subject: RFR: 8352506: Simplify make/test/JtregNativeHotspot.gmk In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 12:32:53 GMT, Magnus Ihse Bursie wrote: > The file to setup special arguments to native JTReg Hotspot tests is needlessly complicated. With some generalisation, we can make it much simpler. I think this is ok, but I would like someone with familiarity with these tests to comment on if adding all include dirs to all tests is a good idea. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24130#pullrequestreview-2703466200 From erikj at openjdk.org Thu Mar 20 17:04:09 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Mar 2025 17:04:09 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: <5CODD75kz7jIXhryLUv2N77BrQVpkBwAUjs3A4QanmM=.3990118b-5e58-4713-9637-152394b3738f@github.com> On Thu, 20 Mar 2025 04:55:32 GMT, Patrick Zhang wrote: > > Wouldn't just the change in JvmFlags.gmk be enough to solve your issue? > > Forgot to mention, one of my initial try-outs (hacking) was: Remove `$(EXTRA_CFLAGS)` from `JVM_CFLAGS`, based on an assumption that all source files under `$(TOPDIR)/src/hotspot` are (according to `hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.d`) and will be C++ files only which has `$(EXTRA_CXXFLAGS)` and does **not** need `$(EXTRA_CFLAGS)` . This practically solved the issue I observed, however I don't think it was an elegant solution. Is this more acceptable than adding parameters to `SetupNativeCompilation` (actually the call to `SetupJdkLibrary`)? I can see what you mean. The current state of the build system is that we aren't consistent with the use of CFLAGS vs CXXFLAGS. For libraries that are C++ or use a mix of C and C++, SetupNativeLibrary will accept flags in two ways, either as just CFLAGS, which will then apply to both C and C++, or as separate CFLAGS and CXXFLAGS, which will then be treated separately. To properly solve your issue, we would need to stop this automatic fallback and be explicit with CFLAGS vs CXXFLAGS throughout the build system. That would certainly be cleaner. Hotspot is currently only C++ and there is little reason to believe that would ever change. The build setup for hotspot is currently only setting CFLAGS, which will then get applied to CXXFLAGS as well. Given that we are currently going with that choice, I think the correct fix is indeed to just remove `EXTRA_CFLAGS` from `JVM_CFLAGS`. If we were to ever add C source files to hotspot, then we would need to start handling JVM_CFLAGS and JVM_CXXFLAGS separately, not just for the EXTRA flags, but for all of them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2741117905 From sgehwolf at openjdk.org Thu Mar 20 17:37:21 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 20 Mar 2025 17:37:21 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 08:27:20 GMT, Christoph Langer wrote: >> Alternative approach to #24012 >> >> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional. >> >> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions. > > After running this patch through our testing I can confirm that it at least solves all existing test issues and does not create regressions. > > I, however, admit that the added code in JRTArchive.java is quite hacky and is actually only there to solve some testing issues, not great. Can we maybe add a possibility to store two alternative SHA sums in the JMod archives, per file? Then we could add SHA sums for both, the stripped and the full pdb file and either one which is present in the current runtime would be accepted. So we'd cover the cases where the stripped pdb files are around as well as a potential case when somebody extracted the symbols archive over the runtime. @RealCLanger I can take a stab at this if you don't mind. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24057#issuecomment-2741191433 From dholmes at openjdk.org Thu Mar 20 21:02:07 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Mar 2025 21:02:07 GMT Subject: RFR: 8352506: Simplify make/test/JtregNativeHotspot.gmk In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 12:32:53 GMT, Magnus Ihse Bursie wrote: > The file to setup special arguments to native JTReg Hotspot tests is needlessly complicated. With some generalisation, we can make it much simpler. make/test/JtregNativeHotspot.gmk line 121: > 119: -I$(VM_TESTBASE_DIR)/nsk/stress/jni \ > 120: -I$(VM_TESTBASE_DIR)/vm/mlvm/share \ > 121: -I$(VM_TESTBASE_DIR)/vm/share \ Including these directories for every native test seems a little risky. Are we sure there are no header files with the same name? Can we not still add these only if the test needs them e.g. if it has vmTestBase in its name for the nsk tests? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24130#discussion_r2006446472 From azvegint at openjdk.org Thu Mar 20 21:33:06 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Mar 2025 21:33:06 GMT Subject: RFR: 8352510: Don't reset LCMS_CFLAGS In-Reply-To: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> References: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> Message-ID: On Thu, 20 Mar 2025 13:15:01 GMT, Magnus Ihse Bursie wrote: > In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250. > > The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up. The [discussion](https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250) mentions another [JBS issue](https://bugs.openjdk.org/browse/JDK-8329173), which I believe should be closed as duplicate of the 8352510. ------------- Marked as reviewed by azvegint (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24131#pullrequestreview-2704166553 From azvegint at openjdk.org Thu Mar 20 22:07:09 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Mar 2025 22:07:09 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 13:06:38 GMT, Matthias Baesken wrote: >> 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. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove AIX special handling from endian.h src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1104: > 1102: Java_sun_awt_screencast_ScreencastHelper_closeSession(JNIEnv *env, jclass cls) { > 1103: } > 1104: Suggestion: This doesn't seem necessary since this method should only be called if `loadPipewire` returns true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2006524200 From ihse at openjdk.org Thu Mar 20 22:22:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 22:22:09 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: References: Message-ID: <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com> On Thu, 20 Mar 2025 22:04:19 GMT, Alexander Zvegintsev wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> remove AIX special handling from endian.h > > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1104: > >> 1102: Java_sun_awt_screencast_ScreencastHelper_closeSession(JNIEnv *env, jclass cls) { >> 1103: } >> 1104: > > Suggestion: > > > > This doesn't seem necessary since this method should only be called if `loadPipewire` returns true. To me it sounds like defensive programming to include an implementation of all native methods, so the JVM will not crash if it mistakenly is called. Do you see a problem with that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2006540766 From ihse at openjdk.org Thu Mar 20 22:25:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 22:25:07 GMT Subject: RFR: 8329173: LCMS_CFLAGS from configure are lost In-Reply-To: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> References: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> Message-ID: On Thu, 20 Mar 2025 13:15:01 GMT, Magnus Ihse Bursie wrote: > In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250. > > The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up. Oh, I missed that. Actually, I think we can stick to the guideline that the older bug has priority, and close the new one as a dup instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24131#issuecomment-2741795833 From azvegint at openjdk.org Thu Mar 20 22:28:08 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Mar 2025 22:28:08 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com> References: <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com> Message-ID: On Thu, 20 Mar 2025 22:19:47 GMT, Magnus Ihse Bursie wrote: >> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1104: >> >>> 1102: Java_sun_awt_screencast_ScreencastHelper_closeSession(JNIEnv *env, jclass cls) { >>> 1103: } >>> 1104: >> >> Suggestion: >> >> >> >> This doesn't seem necessary since this method should only be called if `loadPipewire` returns true. > > To me it sounds like defensive programming to include an implementation of all native methods, so the JVM will not crash if it mistakenly is called. Do you see a problem with that? I do not see a problem here, but in this case the `Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl` is missing, as the ScreencastHelper has 3 native methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2006546267 From ihse at openjdk.org Thu Mar 20 22:28:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 22:28:11 GMT Subject: Integrated: 8329173: LCMS_CFLAGS from configure are lost In-Reply-To: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> References: <-oznIFSOUa2erFDvbX-ABZLyM1iHXtag5jd9PIQYq3k=.be9c77f8-1b22-488e-afff-3f7f92c1a64e@github.com> Message-ID: On Thu, 20 Mar 2025 13:15:01 GMT, Magnus Ihse Bursie wrote: > In [JDK-8329086](https://bugs.openjdk.org/browse/JDK-8329086), when cleaning up the native build for java.desktop, what was likely a bug with LCMS_CFLAGS was found. See the discussion at https://github.com/openjdk/jdk/pull/18486#discussion_r1539179250. > > The old behavior was kept to not introduce any changes in that refactoring PR, but now the time has come to clean this up. This pull request has now been integrated. Changeset: 06ba6cf3 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/06ba6cf3a137a6cdf572a876a46d18e51c248451 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8329173: LCMS_CFLAGS from configure are lost Reviewed-by: erikj, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/24131 From ihse at openjdk.org Thu Mar 20 22:43:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 22:43:07 GMT Subject: RFR: 8352506: Simplify make/test/JtregNativeHotspot.gmk In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 20:59:34 GMT, David Holmes wrote: >> The file to setup special arguments to native JTReg Hotspot tests is needlessly complicated. With some generalisation, we can make it much simpler. > > make/test/JtregNativeHotspot.gmk line 121: > >> 119: -I$(VM_TESTBASE_DIR)/nsk/stress/jni \ >> 120: -I$(VM_TESTBASE_DIR)/vm/mlvm/share \ >> 121: -I$(VM_TESTBASE_DIR)/vm/share \ > > Including these directories for every native test seems a little risky. Are we sure there are no header files with the same name? Can we not still add these only if the test needs them e.g. if it has vmTestBase in its name for the nsk tests? I don't know if it is "risky". Compare this with how all hotspot files are compiled, with all these include directories: build/macosx-aarch64/hotspot/variant-server/gensrc build/macosx-aarch64/hotspot/variant-server/gensrc/adfiles build/macosx-aarch64/support/modules_include/java.base build/macosx-aarch64/support/modules_include/java.base/darwin open/src/hotspot/cpu/aarch64 open/src/hotspot/os_cpu/bsd_aarch64 open/src/hotspot/os/bsd open/src/hotspot/os/posix open/src/hotspot/os/posix/include open/src/hotspot/share open/src/hotspot/share/include open/src/java.base/share/native/include open/src/java.base/share/native/libjimage open/src/java.base/unix/native/include Are we sure that there are no header files of the same name here? We can check, and there are none. Can we be sure that no one will add a conflicting header? Well, yes, since then the product would not compile as expected. Going back to the test files. This is the complete list of all header files present in these directories: test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.hpp test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.hpp test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.hpp test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.hpp test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.hpp test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.hpp test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.hpp test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.hpp test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.hpp test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.hpp test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_mutex.hpp test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp test/hotspot/jtreg/vmTestbase/nsk/stress/jni/jnihelper.hpp test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.hpp test/lib/jdk/test/lib/jvmti/jvmti_common.hpp test/lib/jdk/test/lib/jvmti/jvmti_thread.hpp As you can see, there are no conflicts. Most of the names are very specific and include some part of their specific "package" in the name. It seems highly unlikely to me that someone would add another header file with the same name as any of these. And, also, if someone were to do that after this PR, the tests would fail to compile as expected, so it can't really happen by mistake. (I do note the weird fact that there is both a `jvmti_tools.hpp` and a `JVMTITools.hpp` in `test/hotspot/jtreg/vmTestbase/nsk/share/jvmti`. Seems confused to me.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24130#discussion_r2006562840 From ihse at openjdk.org Thu Mar 20 22:48:08 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Mar 2025 22:48:08 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: References: <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com> Message-ID: <5iG5N6DZIOjN0AolXJRm_l5-eqaKOnk_i_Xza6tKYKc=.1f2dfd70-0c6b-4b95-bf39-afaefddca709@github.com> On Thu, 20 Mar 2025 22:25:49 GMT, Alexander Zvegintsev wrote: >> To me it sounds like defensive programming to include an implementation of all native methods, so the JVM will not crash if it mistakenly is called. Do you see a problem with that? > > I do not see a problem here, but in this case the `Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl` is missing, as the ScreencastHelper has 3 native methods. Ah, I see. I agree, that it makes more sense to either include all native methods, or skip all that are never called. Adding a dummy implementation of one but not all seems ... weird. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2006566872 From dholmes at openjdk.org Fri Mar 21 03:20:22 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 21 Mar 2025 03:20:22 GMT Subject: RFR: 8351322: Parameterize link option for pthreads [v2] In-Reply-To: References: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com> Message-ID: On Thu, 20 Mar 2025 12:38:37 GMT, Magnus Ihse Bursie wrote: > Is there any gain then in changing away from -lpthread? That is clearly defined, link with libpthread, with no side effects. "If it ain't broke..." True - what we have works and using `-pthread` might subtly change things. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2742145168 From dholmes at openjdk.org Fri Mar 21 06:39:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 21 Mar 2025 06:39:12 GMT Subject: RFR: 8352506: Simplify make/test/JtregNativeHotspot.gmk In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 22:40:51 GMT, Magnus Ihse Bursie wrote: >> make/test/JtregNativeHotspot.gmk line 121: >> >>> 119: -I$(VM_TESTBASE_DIR)/nsk/stress/jni \ >>> 120: -I$(VM_TESTBASE_DIR)/vm/mlvm/share \ >>> 121: -I$(VM_TESTBASE_DIR)/vm/share \ >> >> Including these directories for every native test seems a little risky. Are we sure there are no header files with the same name? Can we not still add these only if the test needs them e.g. if it has vmTestBase in its name for the nsk tests? > > I don't know if it is "risky". Compare this with how all hotspot files are compiled, with all these include directories: > > build/macosx-aarch64/hotspot/variant-server/gensrc > build/macosx-aarch64/hotspot/variant-server/gensrc/adfiles > build/macosx-aarch64/support/modules_include/java.base > build/macosx-aarch64/support/modules_include/java.base/darwin > open/src/hotspot/cpu/aarch64 > open/src/hotspot/os_cpu/bsd_aarch64 > open/src/hotspot/os/bsd > open/src/hotspot/os/posix > open/src/hotspot/os/posix/include > open/src/hotspot/share > open/src/hotspot/share/include > open/src/java.base/share/native/include > open/src/java.base/share/native/libjimage > open/src/java.base/unix/native/include > > > Are we sure that there are no header files of the same name here? We can check, and there are none. Can we be sure that no one will add a conflicting header? Well, yes, since then the product would not compile as expected. > > Going back to the test files. This is the complete list of all header files present in these directories: > > test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_mutex.hpp > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp > test/hotspot/jtreg/vmTestbase/nsk/stress/jni/jnihelper.hpp > test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.hpp > test/lib/jdk/test/lib/jvmti/jvmti_common.hpp > test/lib/jdk/test/lib/jvmti/jvmti_thread.hpp > > > As you can see, there are no conflicts. > > Most of the names are very specific and include some part of their specific "package" in the name. It seems highly unlikely to me that someone would add another header file with the same name as any of these. > > And, also, if someone were to do that after this PR, the tests would fail to compile as expected, so it can't really happen by mistake. > > (I do note the weird fact that there is both a `jvmti_tools.hpp` a... Okay, lets give it a try. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24130#discussion_r2006936847 From mbaesken at openjdk.org Fri Mar 21 08:28:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 21 Mar 2025 08:28:07 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v2] In-Reply-To: <5iG5N6DZIOjN0AolXJRm_l5-eqaKOnk_i_Xza6tKYKc=.1f2dfd70-0c6b-4b95-bf39-afaefddca709@github.com> References: <8C6-gWw0DHkYptvj3D_kGW9FPWBtj_LZXPiNZ46a5Pg=.91f86ffd-1671-45e9-ba59-8cef2f9e8872@github.com> <5iG5N6DZIOjN0AolXJRm_l5-eqaKOnk_i_Xza6tKYKc=.1f2dfd70-0c6b-4b95-bf39-afaefddca709@github.com> Message-ID: On Thu, 20 Mar 2025 22:45:47 GMT, Magnus Ihse Bursie wrote: >> I do not see a problem here, but in this case the `Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl` is missing, as the ScreencastHelper has 3 native methods. > > Ah, I see. I agree, that it makes more sense to either include all native methods, or skip all that are never called. Adding a dummy implementation of one but not all seems ... weird. Okay then let's do defensive programming and add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl too . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24009#discussion_r2007074495 From mbaesken at openjdk.org Fri Mar 21 08:58:36 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 21 Mar 2025 08:58:36 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v3] In-Reply-To: References: Message-ID: > 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. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24009/files - new: https://git.openjdk.org/jdk/pull/24009/files/e7941d37..79ec8a7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24009&range=01-02 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 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 ihse at openjdk.org Fri Mar 21 10:23:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 10:23:21 GMT Subject: Integrated: 8352506: Simplify make/test/JtregNativeHotspot.gmk In-Reply-To: References: Message-ID: <9adtUEf2tcDdcX3CAQ0FESAx-mNzuAjdKlGDRAZDn8k=.bd02a3de-ac23-4c77-837f-42d98f346220@github.com> On Thu, 20 Mar 2025 12:32:53 GMT, Magnus Ihse Bursie wrote: > The file to setup special arguments to native JTReg Hotspot tests is needlessly complicated. With some generalisation, we can make it much simpler. This pull request has now been integrated. Changeset: 07667ca2 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/07667ca2f40782bd50e2551ab9f24bee38ae2bfb Stats: 1527 lines in 2 files changed: 35 ins; 1447 del; 45 mod 8352506: Simplify make/test/JtregNativeHotspot.gmk Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/24130 From ihse at openjdk.org Fri Mar 21 10:31:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 10:31:07 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v3] In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > added needed include Regaring point 2: the current solution works, and is acceptable, I think. The two excluded files only contain the dladdr() implementation, and this is implemented in hotspot, so no functionality is lost. Compacting this into just a single implementation is a separate issue, and need not be resolved now. Regarding the name of `_generate_export_list_libjli.a_exec`: this is generated from the name of the SetupExecute rule, `generate_export_list_$(lib)`. I don't mind the name, it is clear. I don't see any particular point in keeping the name short, but if it bothers you, shorten the name of the rule. Try keeping it clear what it does, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2742949097 From ihse at openjdk.org Fri Mar 21 10:36:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 10:36:16 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v3] In-Reply-To: References: Message-ID: <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com> On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > added needed include make/StaticLibs.gmk line 117: > 115: OUTPUT_FILE := $(lib).exp, \ > 116: COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \ > 117: )) \ To better align with how we store the targets of Setup calls, can you please change this to: Suggestion: STATIC_LIBS := -Wl,-bexpfull $(STATIC_LIB_FILES) $(addprefix -Wl$(COMMA)-bE:, $(STATIC_LIB_EXPORT_FILES)) $(foreach lib, $(STATIC_LIB_FILES), \ $(eval $(call SetupExecute, generate_export_list_$(notdir $(lib)), \ INFO := Generating export list for $(notdir $(lib)), \ DEPS := $(lib), \ OUTPUT_FILE := $(lib).exp, \ COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \ )) \ $(eval STATIC_LIB_EXPORT_FILES += $(lib).exp) \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007298830 From ihse at openjdk.org Fri Mar 21 10:44:06 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 10:44:06 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 06:57:04 GMT, SendaoYan wrote: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data Are you saying that running `clang -Wl,-v` sometimes, but not consistently, generated an `a.out` file for you? That's really absurd and clearly a bug in clang/lld. Have you reported this upstream? If this really happens and is a problem for you, I can accept that we will need to carry a workaround to delete the file. But you need to add a comment saying that this is a workaround, with a link to the upstream bug so we know when we can remove it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2742981116 From ihse at openjdk.org Fri Mar 21 10:54:22 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 10:54:22 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v3] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken wrote: >> 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. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2705508010 From jkern at openjdk.org Fri Mar 21 11:44:49 2025 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 21 Mar 2025 11:44:49 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v4] In-Reply-To: References: Message-ID: > After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. > > Now with this change we can enable the statically linked launcher target again. > There are 3 things to do. > 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. > 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. > 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: follow Magnus ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24062/files - new: https://git.openjdk.org/jdk/pull/24062/files/200c36f4..9b92eea7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=02-03 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24062.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062 PR: https://git.openjdk.org/jdk/pull/24062 From jkern at openjdk.org Fri Mar 21 11:44:49 2025 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 21 Mar 2025 11:44:49 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v3] In-Reply-To: <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com> References: <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com> Message-ID: On Fri, 21 Mar 2025 10:33:10 GMT, Magnus Ihse Bursie wrote: >> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: >> >> added needed include > > make/StaticLibs.gmk line 117: > >> 115: OUTPUT_FILE := $(lib).exp, \ >> 116: COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \ >> 117: )) \ > > To better align with how we store the targets of Setup calls, can you please change this to: > > Suggestion: > > STATIC_LIBS := -Wl,-bexpfull $(STATIC_LIB_FILES) $(addprefix -Wl$(COMMA)-bE:, $(STATIC_LIB_EXPORT_FILES)) > $(foreach lib, $(STATIC_LIB_FILES), \ > $(eval $(call SetupExecute, generate_export_list_$(notdir $(lib)), \ > INFO := Generating export list for $(notdir $(lib)), \ > DEPS := $(lib), \ > OUTPUT_FILE := $(lib).exp, \ > COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \ > )) \ > $(eval STATIC_LIB_EXPORT_FILES += $(lib).exp) \ Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007406147 From syan at openjdk.org Fri Mar 21 12:27:11 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 21 Mar 2025 12:27:11 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 10:40:34 GMT, Magnus Ihse Bursie wrote: > Are you saying that running `clang -Wl,-v` sometimes, but not consistently, generated an `a.out` file for you? That's really absurd and clearly a bug in clang/lld. Have you reported this upstream? > > If this really happens and is a problem for you, I can accept that we will need to carry a workaround to delete the file. But you need to add a comment saying that this is a workaround, with a link to the upstream bug so we know when we can remove it. Only when clang `-Wl,-v` and head command are used with pipeline, and clang uses absolute path, `a.out` will be intermittently generated. I am not sure whether this is a bug of clang or a bug of head command. I will submit an issue in llvm community for confirmation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2743215790 From ihse at openjdk.org Fri Mar 21 12:39:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 12:39:09 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 06:57:04 GMT, SendaoYan wrote: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data I now realized that you are using the binutils ld with clang. This is not a supported combination. You are likely to run into additional problems with this. Please use `lld` instead when using clang. The a.out file is created by the linker, not the compiler, so this likely happens either due to a bug in the binutils `ld`, or due to some combination of clang and ld. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2743244239 From ihse at openjdk.org Fri Mar 21 12:44:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 12:44:07 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v4] In-Reply-To: References: Message-ID: <9rfZiM27z9h-LAwYXUYSX7nD0dp1oejodRIUT-S8z94=.d5206ba4-18fe-4a88-ad0a-aa3029f2b834@github.com> On Fri, 21 Mar 2025 11:44:49 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > follow Magnus The build changes look good to me now. You need to have someone review the hotspot AIX changes as well. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2705808054 From syan at openjdk.org Fri Mar 21 12:58:06 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 21 Mar 2025 12:58:06 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 06:57:04 GMT, SendaoYan wrote: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data I did not specify which linker to use in the configure command line, I only specified the clang toolchain, and when clang is selected as the toolchain, lld should be automatically selected as the linker. However, the problematic line of command did not receive the linker name, causing this problem ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2743287237 From clanger at openjdk.org Fri Mar 21 14:04:14 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 21 Mar 2025 14:04:14 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 17:28:54 GMT, Severin Gehwolf wrote: >> After running this patch through our testing I can confirm that it at least solves all existing test issues and does not create regressions. >> >> I, however, admit that the added code in JRTArchive.java is quite hacky and is actually only there to solve some testing issues, not great. Can we maybe add a possibility to store two alternative SHA sums in the JMod archives, per file? Then we could add SHA sums for both, the stripped and the full pdb file and either one which is present in the current runtime would be accepted. So we'd cover the cases where the stripped pdb files are around as well as a potential case when somebody extracted the symbols archive over the runtime. > > @RealCLanger I can take a stab at this if you don't mind. Thanks @jerboaa. Waiting for your result then ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24057#issuecomment-2743458144 From ihse at openjdk.org Fri Mar 21 15:36:30 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 15:36:30 GMT Subject: RFR: 8196896: Use SYSROOT_CFLAGS in dtrace gensrc Message-ID: We are missing `$(SYSROOT_CFLAGS)` when calling `$(CPP)` directly (instead of going via `SetupNativeCompilation`). ------------- Commit messages: - 8196896: Use SYSROOT_CFLAGS in dtrace gensrc Changes: https://git.openjdk.org/jdk/pull/24160/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8196896 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24160/head:pull/24160 PR: https://git.openjdk.org/jdk/pull/24160 From ihse at openjdk.org Fri Mar 21 15:40:26 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Mar 2025 15:40:26 GMT Subject: RFR: 8352618: Remove old deprecated functionality in the build system Message-ID: It's time for some spring cleaning in the build system. These checks are for functionality that has long been deprecated, and should not be in use anymore. We should remove it to keep the code base simpler. ------------- Commit messages: - 8352618: Remove old deprecated functionality in the build system Changes: https://git.openjdk.org/jdk/pull/24159/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352618 Stats: 64 lines in 10 files changed: 0 ins; 57 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24159/head:pull/24159 PR: https://git.openjdk.org/jdk/pull/24159 From mdoerr at openjdk.org Fri Mar 21 16:02:17 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 21 Mar 2025 16:02:17 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v4] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 11:44:49 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > follow Magnus I'm not really familiar with it, but I have some code style requests. src/hotspot/os/aix/loadlib_aix.cpp line 218: > 216: procentry64 PInfo; > 217: PInfo.pi_pid = ::getpid(); > 218: if ( 0 == ::getargs(&PInfo, sizeof(PInfo), (char*)pgmpath,PATH_MAX) && *pgmpath ) { Coding style: spaces after `(` and before `)` are uncommon, but we should have one before `PATH_MAX`. I think hotspot style guide compliant would be: `if (0 == ::getargs(&PInfo, sizeof(PInfo), (char*)pgmpath, PATH_MAX) && *pgmpath != 0)` src/hotspot/os/aix/loadlib_aix.cpp line 221: > 219: pgmpath[PATH_MAX] = '\0'; > 220: pgmbase = strrchr(pgmpath, '/'); > 221: if (pgmbase) { Better: `if (pgmbase != nullptr)` src/hotspot/os/aix/loadlib_aix.cpp line 222: > 220: pgmbase = strrchr(pgmpath, '/'); > 221: if (pgmbase) { > 222: pgmbase +=1; Maybe add a space: "+= 1"? src/hotspot/os/aix/loadlib_aix.cpp line 245: > 243: lm->data_len = ldi->ldinfo_datasize; > 244: > 245: if (pgmbase && 0 == strcmp(pgmbase, ldi->ldinfo_filename)) { `pmgbase != nullptr` ------------- PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2706439265 PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007864471 PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007869385 PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007866684 PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007870732 From jkern at openjdk.org Fri Mar 21 16:19:38 2025 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 21 Mar 2025 16:19:38 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v5] In-Reply-To: References: Message-ID: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> > After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. > > Now with this change we can enable the statically linked launcher target again. > There are 3 things to do. > 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. > 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. > 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: follow Martin ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24062/files - new: https://git.openjdk.org/jdk/pull/24062/files/9b92eea7..3d9fcafc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24062.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062 PR: https://git.openjdk.org/jdk/pull/24062 From erikj at openjdk.org Fri Mar 21 16:36:08 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 21 Mar 2025 16:36:08 GMT Subject: RFR: 8196896: Use SYSROOT_CFLAGS in dtrace gensrc In-Reply-To: References: Message-ID: <8g9RMMakZyu2HZbqjfAHof39O3Mk_2rZ9l72HMDMOGs=.f9bc3e16-0cef-4307-8bf9-35e84218f516@github.com> On Fri, 21 Mar 2025 15:30:58 GMT, Magnus Ihse Bursie wrote: > We are missing `$(SYSROOT_CFLAGS)` when calling `$(CPP)` directly (instead of going via `SetupNativeCompilation`). Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24160#pullrequestreview-2706567367 From erikj at openjdk.org Fri Mar 21 16:39:17 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 21 Mar 2025 16:39:17 GMT Subject: RFR: 8352618: Remove old deprecated functionality in the build system In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 15:17:27 GMT, Magnus Ihse Bursie wrote: > It's time for some spring cleaning in the build system. These checks are for functionality that has long been deprecated, and should not be in use anymore. We should remove it to keep the code base simpler. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24159#pullrequestreview-2706574557 From kbarrett at openjdk.org Fri Mar 21 16:43:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 21 Mar 2025 16:43:16 GMT Subject: RFR: 8352618: Remove old deprecated functionality in the build system In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 15:17:27 GMT, Magnus Ihse Bursie wrote: > It's time for some spring cleaning in the build system. These checks are for functionality that has long been deprecated, and should not be in use anymore. We should remove it to keep the code base simpler. Nice cleanup. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24159#pullrequestreview-2706585910 From azvegint at openjdk.org Fri Mar 21 16:50:10 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 21 Mar 2025 16:50:10 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v3] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken wrote: >> 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. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2706602971 From mdoerr at openjdk.org Fri Mar 21 16:59:14 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 21 Mar 2025 16:59:14 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v5] In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> References: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> Message-ID: On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > follow Martin LGTM. Maybe @MBaesken wants to take a look at the AIX code, too? ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2706624142 From jwaters at openjdk.org Fri Mar 21 17:23:08 2025 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 21 Mar 2025 17:23:08 GMT Subject: RFR: 8352618: Remove old deprecated functionality in the build system In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 15:17:27 GMT, Magnus Ihse Bursie wrote: > It's time for some spring cleaning in the build system. These checks are for functionality that has long been deprecated, and should not be in use anymore. We should remove it to keep the code base simpler. Go for it! ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/24159#pullrequestreview-2706683941 From xtex at envs.net Sat Mar 22 00:55:19 2025 From: xtex at envs.net (Bingwu Zhang) Date: Sat, 22 Mar 2025 08:55:19 +0800 Subject: javac stack overflow on loongson3 with zero variant Message-ID: <4641863.LvFx2qVVIh@xtex1> Hi! Recently when packaging OpenJDK 24-ga for AOSC OS, I hit an compilation error on loongson3 (which is a variant of mips64), saying that javac is running out of stack space: > java.lang.StackOverflowError > at jdk.compiler.interim/ com.sun.tools.javac.code.Type.constValue(Type.java:186) > at jdk.compiler.interim/ com.sun.tools.javac.code.Type$JCPrimitiveType.isFalse(Type.java:823) > at jdk.compiler.interim/ com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanCond(Flow.java:2365) > at jdk.compiler.interim/ com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBinary(Flow.java:3181) > at jdk.compiler.interim/ com.sun.tools.javac.tree.JCTree$JCBinary.accept(JCTree.java:2221) > at jdk.compiler.interim/ com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50) > at jdk.compiler.interim/ com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463) > at jdk.compiler.interim/ com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2097) > at jdk.compiler.interim/ com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanCond(Flow.java:2382) > at jdk.compiler.interim/ com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBinary(Flow.java:3181) > at jdk.compiler.interim/ com.sun.tools.javac.tree.JCTree$JCBinary.accept(JCTree.java:2221) > ... (rest of output omitted) For the full build log, please see the log of our build system [1]. We use zero variant for loongson3 currently (and it is the only architecture we supported using zero). As it build on other architectures properly, I think it is likely just because the default stack size is too small, unlikely to be a dead loop in javac. I attempted to add "--with-boot-jdk-jvmargs=-Xss256M" to extend the thread stack size but it changed nothing. The configure command is: > bash configure --with-jvm-variants=zero --enable-precompiled-headers --with- boot-jdk-jvmargs=-Xss256M --with-conf-name=aosc --with-stdc++lib=dynamic -- disable-warnings-as-errors --enable-linktime-gc --with-native-debug- symbols=zipped What should I try next? Is this a bug or a even larger stack is required? [1] https://buildit.aosc.io/logs/73789-openjdk-24-loongson3-Misaka23333-2025-03-22-03:32:47.txt -- Bingwu Zhang (@xtex) @ Fri, 21 Mar 2025 23:12:49 +0000 From syan at openjdk.org Sat Mar 22 03:46:49 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 22 Mar 2025 03:46:49 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v2] In-Reply-To: References: Message-ID: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Add a comment line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24125/files - new: https://git.openjdk.org/jdk/pull/24125/files/9931cf85..5f92746d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24125/head:pull/24125 PR: https://git.openjdk.org/jdk/pull/24125 From syan at openjdk.org Sat Mar 22 03:46:49 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 22 Mar 2025 03:46:49 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 06:57:04 GMT, SendaoYan wrote: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data I have add a comment line do demonstrate why we need `RM -rf a.out`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2744952540 From jpai at openjdk.org Sat Mar 22 04:48:06 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 22 Mar 2025 04:48:06 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang In-Reply-To: References: Message-ID: On Sat, 22 Mar 2025 03:43:58 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > I have add a comment line do demonstrate why we need `RM -rf a.out`. Hello @sendaoYan, I don't have knowledge of these build files so I'll let the build team decide if this change is needed. However, is the `-rf` needed in that `rm` command? Would just `rm a.out` not work? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2744986563 From syan at openjdk.org Sat Mar 22 06:50:48 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 22 Mar 2025 06:50:48 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v3] In-Reply-To: References: Message-ID: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Use "-f" parameter instead of "-rf" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24125/files - new: https://git.openjdk.org/jdk/pull/24125/files/5f92746d..c37637ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24125/head:pull/24125 PR: https://git.openjdk.org/jdk/pull/24125 From syan at openjdk.org Sat Mar 22 06:50:48 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 22 Mar 2025 06:50:48 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang In-Reply-To: References: Message-ID: On Sat, 22 Mar 2025 03:43:58 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > I have add a comment line do demonstrate why we need `RM -rf a.out`. > Hello @sendaoYan, I don't have knowledge of these build files so I'll let the build team decide if this change is needed. However, is the `-rf` needed in that `rm` command? Would just `rm a.out` not work? Hello @jaikiran There is a small probability that a.out will not be generated, so I use `-rf` paramater to avoid print error message when there is no a.out file. I think we should use `-f` instead of `-rf`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2745086955 From qpzhang at openjdk.org Sat Mar 22 10:09:46 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Sat, 22 Mar 2025 10:09:46 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: > Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. > > The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. > > This PR does: > 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. > 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. > 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. > > Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. Patrick Zhang has updated the pull request incrementally with three additional commits since the last revision: - Fixed a typo Signed-off-by: Patrick Zhang - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS Signed-off-by: Patrick Zhang - Revert the changes of adding new params to SetupNativeCompilation Signed-off-by: Patrick Zhang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24115/files - new: https://git.openjdk.org/jdk/pull/24115/files/cf61e94a..aa242dd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=00-01 Stats: 9 lines in 5 files changed: 3 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24115/head:pull/24115 PR: https://git.openjdk.org/jdk/pull/24115 From qpzhang at openjdk.org Sat Mar 22 10:13:06 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Sat, 22 Mar 2025 10:13:06 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: <5CODD75kz7jIXhryLUv2N77BrQVpkBwAUjs3A4QanmM=.3990118b-5e58-4713-9637-152394b3738f@github.com> References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> <5CODD75kz7jIXhryLUv2N77BrQVpkBwAUjs3A4QanmM=.3990118b-5e58-4713-9637-152394b3738f@github.com> Message-ID: On Thu, 20 Mar 2025 16:59:20 GMT, Erik Joelsson wrote: > Given that we are currently going with that choice, I think the correct fix is indeed to just remove `EXTRA_CFLAGS` from `JVM_CFLAGS`. Thanks for your kindly advise @erikj79, I updated it accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2745194915 From mbaesken at openjdk.org Mon Mar 24 08:34:22 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Mar 2025 08:34:22 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v3] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken wrote: >> 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. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case Thanks for the review ! Phil - do you have more comments ? If not I would like to integrate it soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2747289351 From sgehwolf at openjdk.org Mon Mar 24 10:42:26 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 24 Mar 2025 10:42:26 GMT Subject: RFR: 8352692: Add support for extra jlink options Message-ID: Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. Testing: - [ ] GHA (currently running) - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. Thoughts? ------------- Commit messages: - 8352692: Add support for extra jlink options Changes: https://git.openjdk.org/jdk/pull/24188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352692 Stats: 15 lines in 3 files changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24188/head:pull/24188 PR: https://git.openjdk.org/jdk/pull/24188 From fthevene at redhat.com Mon Mar 24 11:24:39 2025 From: fthevene at redhat.com (Frederic Thevenet) Date: Mon, 24 Mar 2025 12:24:39 +0100 Subject: [Proposal] Add code signing on Windows to the JDK build system In-Reply-To: References: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com> <79bc54ec-fd5d-4803-914d-01c64ef88a98@redhat.com> <1f1fd802-72e0-4b27-9a77-9d9ed913caf3@oracle.com> <37182570-6ec8-47cc-8560-b3014f07df2c@oracle.com> <4e501adc-aed7-4c56-8157-155b87b732b4@redhat.com> Message-ID: <2f9cb978-aa77-4ef2-b589-6eb2399c3d4a@redhat.com> Hi, I have reworked my PR so that using the signing hook is no longer restrained to a specific platform. Please note that I have not touched the current code signing implementation for macOS; to me, it seems simpler to have both options live side by side, at least for the time being. If you feel that this is moving into the right direction, I'm thinking it might be time to remove the draft status on the PR and continue our discussion on the subject over there. Wdyt? Thanks, Frederic On 13/03/2025 10:39, Magnus Ihse Bursie wrote: > On 2025-03-11 20:29, Frederic Thevenet wrote: > >> 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? > > Hm, that is definitely an interesting take. I'm a big fan of > "right-sizing" generalization; I think both too much and too little > generalization is detrimental. My gut feeling right now is that we > should keep this focused on what it is, a way to allow signing. It > will make the functionality discoverable by other parties that would > like to add their own signing script; a general "hook" system might > not. But it's good to keep in mind in case any future, non-signing > needs arise. > > I was more thinking along the lines that the current macOS signing > could be considered/rewritten in terms of a "signing hook", with the > exception that we also ship a default implementation alongside in the > build system. If we do that right, we could probably retrofit Oracle's > internal macOS signing logic into the same framework, which would be > nice. But then again, that is definitely feature creep wrt to your > original request. So maybe we can come back and revisit that thought > later. > > /Magnus > >> >> 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: 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 BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92 From sgehwolf at openjdk.org Mon Mar 24 13:25:06 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 24 Mar 2025 13:25:06 GMT Subject: RFR: 8352692: Add support for extra jlink options In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 10:37:10 GMT, Severin Gehwolf wrote: > Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. > > Testing: > - [x] GHA > - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. > > Thoughts? `test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java` GHA failure is unrelated to this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24188#issuecomment-2748120210 From erikj at openjdk.org Mon Mar 24 13:30:16 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 24 Mar 2025 13:30:16 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v3] In-Reply-To: References: Message-ID: On Sat, 22 Mar 2025 06:50:48 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Use "-f" parameter instead of "-rf" make/autoconf/toolchain.m4 line 536: > 534: > 535: LINKER_VERSION_STRING=`$LINKER -Wl,-v 2>&1 | $HEAD -n 1` > 536: # Remove redundant a.out generated by clang, to workaound clang bug https://github.com/llvm/llvm-project/issues/132388 Spelling and line length, otherwise this looks ok. Suggestion: # Remove redundant a.out generated by clang, to work around clang bug # https://github.com/llvm/llvm-project/issues/132388 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24125#discussion_r2010181942 From erikj at openjdk.org Mon Mar 24 13:34:07 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 24 Mar 2025 13:34:07 GMT Subject: RFR: 8352692: Add support for extra jlink options In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 10:37:10 GMT, Severin Gehwolf wrote: > Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. > > Testing: > - [x] GHA > - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. > > Thoughts? I think this makes sense on its own. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24188#pullrequestreview-2710398304 From mbaesken at openjdk.org Mon Mar 24 14:33:16 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Mar 2025 14:33:16 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v5] In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> References: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> Message-ID: <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com> On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > follow Martin Regarding BitmapToYXBandedRectangles from splashscreen, couldn't we just rename it to avoid clashes/issues with the other one from awt with the same name but other signature? But this can be done in another issue/PR not here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748329252 From mbaesken at openjdk.org Mon Mar 24 14:40:15 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Mar 2025 14:40:15 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v5] In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> References: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> Message-ID: On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > follow Martin src/hotspot/os/aix/loadlib_aix.cpp line 245: > 243: lm->data_len = ldi->ldinfo_datasize; > 244: > 245: if (pgmbase != nullptr && 0 == strcmp(pgmbase, ldi->ldinfo_filename)) { Maybe better `strcmp(...) == 0 ` this is what we use almost everywhere in the HS codebase . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2010314259 From mbaesken at openjdk.org Mon Mar 24 14:47:16 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Mar 2025 14:47:16 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v5] In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> References: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> Message-ID: <8TwaUDdIMp-LNCl2y4Yujed7OooXrKcCAw80VMVQVKc=.fe956a84-6f75-4273-86fd-cde786fce017@github.com> On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > follow Martin Looks okay, small nit inside. I would prefer more self explaining variable names like program_full_path , program_base_name but up to you! ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2710649870 From ihse at openjdk.org Mon Mar 24 15:30:17 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Mar 2025 15:30:17 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v5] In-Reply-To: <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com> References: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com> Message-ID: On Mon, 24 Mar 2025 14:30:02 GMT, Matthias Baesken wrote: > Regarding BitmapToYXBandedRectangles from splashscreen, couldn't we just rename it to avoid clashes/issues with the other one from awt with the same name but other signature? But this can be done in another issue/PR not here. Indeed we could. Note that the same issue apply to all unix platforms. It's sort of a hack -- the core problem is that we cannot hide non-exported symbols in static libraries. Solving that is the long-term goal, but it is tricky on several platforms. It could make sense to try to unify the two versions of BitmapToYXBandedRectangles as well; they are similar but not identical (but I can't really tell why). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748527590 From syan at openjdk.org Mon Mar 24 15:31:23 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 24 Mar 2025 15:31:23 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v4] In-Reply-To: References: Message-ID: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data SendaoYan has updated the pull request incrementally with one additional commit since the last revision: fix spelling bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24125/files - new: https://git.openjdk.org/jdk/pull/24125/files/c37637ca..ab3f5d91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24125/head:pull/24125 PR: https://git.openjdk.org/jdk/pull/24125 From syan at openjdk.org Mon Mar 24 15:31:24 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 24 Mar 2025 15:31:24 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v3] In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 13:27:19 GMT, Erik Joelsson wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use "-f" parameter instead of "-rf" > > make/autoconf/toolchain.m4 line 536: > >> 534: >> 535: LINKER_VERSION_STRING=`$LINKER -Wl,-v 2>&1 | $HEAD -n 1` >> 536: # Remove redundant a.out generated by clang, to workaound clang bug https://github.com/llvm/llvm-project/issues/132388 > > Spelling and line length, otherwise this looks ok. > Suggestion: > > # Remove redundant a.out generated by clang, to work around clang bug > # https://github.com/llvm/llvm-project/issues/132388 Thanks. PR has been updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24125#discussion_r2010412509 From ihse at openjdk.org Mon Mar 24 15:34:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Mar 2025 15:34:10 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v4] In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 15:31:23 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > fix spelling bug `RM` is actually defined as `rm -f` so the `-f` is not necessary. I'm still not very happy with this solution. It will remove any `a.out` file the user has lying around. Granted, they are normally temporary testing files, but it is highly surprising that running `configure` should remove them. To fix that, we would need to check for the existence of `a.out` prior to running the link command to set a flag if we should allow deletion or not. That would make the patch more complex. So I don't think this is the right way to go. Later on, we will pass `-fuse-ld=lld` to `clang`. I think the correct fix is to make sure it is always passed, from the very beginning, even when checking version strings etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2748540061 From mbaesken at openjdk.org Mon Mar 24 15:49:20 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Mar 2025 15:49:20 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v5] In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> References: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> Message-ID: On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote: >> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. >> >> Now with this change we can enable the statically linked launcher target again. >> There are 3 things to do. >> 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. >> 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. >> 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > follow Martin Seems we use already a bit of functionality from common/awt in the splashscreen lib 140 ifeq ($(ENABLE_HEADLESS_ONLY), false) 141 LIBSPLASHSCREEN_EXTRA_SRC := \ 142 common/awt/systemscale \ 143 # 144 145 LIBSPLASHSCREEN_HEADER_DIRS := \ 146 common/awt/utility \ maybe it would make sense to centralize the BitmapToYXBandedRectangles there and reuse it from there? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748584904 From jkern at openjdk.org Mon Mar 24 16:18:15 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 24 Mar 2025 16:18:15 GMT Subject: Integrated: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern wrote: > After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again. > > Now with this change we can enable the statically linked launcher target again. > There are 3 things to do. > 1. Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself. > 2. `dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides. > 3. Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome. This pull request has now been integrated. Changeset: d8c2f59a Author: Joachim Kern URL: https://git.openjdk.org/jdk/commit/d8c2f59a1b28521ab9969fdf71c52726026d2a85 Stats: 68 lines in 5 files changed: 63 ins; 3 del; 2 mod 8352064: AIX: now also able to build static-jdk image with a statically linked launcher Reviewed-by: mdoerr, mbaesken, ihse ------------- PR: https://git.openjdk.org/jdk/pull/24062 From ihse at openjdk.org Mon Mar 24 17:07:17 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Mar 2025 17:07:17 GMT Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a statically linked launcher [v5] In-Reply-To: References: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com> Message-ID: <3hZLvynYqp2oIj5l7-fC764K5KCM08ooRvWq3woHYlI=.85ae9e1d-bf14-4b73-be13-6729f2add58a@github.com> On Mon, 24 Mar 2025 15:46:03 GMT, Matthias Baesken wrote: > Seems we use already a bit of functionality from common/awt in the splashscreen lib Maybe. The client team has traditionally been very conservative about doing clean-up changes like that, so you might be entering an uphill battle if you want to do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748828065 From ihse at openjdk.org Mon Mar 24 17:09:12 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Mar 2025 17:09:12 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with three additional commits since the last revision: > > - Fixed a typo > > Signed-off-by: Patrick Zhang > - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS > > Signed-off-by: Patrick Zhang > - Revert the changes of adding new params to SetupNativeCompilation > > Signed-off-by: Patrick Zhang make/common/native/Flags.gmk line 125: > 123: endif > 124: ifeq ($(STATIC_LIBS), true) > 125: $1_EXTRA_CXXFLAGS += -DSTATIC_BUILD=1 This seems unrelated to the fix? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24115#discussion_r2010600970 From ihse at openjdk.org Mon Mar 24 18:46:24 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Mar 2025 18:46:24 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with three additional commits since the last revision: > > - Fixed a typo > > Signed-off-by: Patrick Zhang > - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS > > Signed-off-by: Patrick Zhang > - Revert the changes of adding new params to SetupNativeCompilation > > Signed-off-by: Patrick Zhang make/hotspot/lib/JvmFlags.gmk line 89: > 87: endif > 88: > 89: # Hotspot currently supports only C++. To prevent compilation conflicts, I don't think this comments serves any purpose. It was probably a mistake to include EXTRA_CFLAGS here to begin with. After this PR, no one is going to miss it, so the comment will make no sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24115#discussion_r2010743373 From prr at openjdk.org Mon Mar 24 19:53:14 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Mar 2025 19:53:14 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v3] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken wrote: >> 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. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case Marked as reviewed by prr (Reviewer). Sorry, the job was slow and I was otherwise busy last week and forgot. Approving now since testing was OK. ------------- PR Review: https://git.openjdk.org/jdk/pull/24009#pullrequestreview-2711528266 PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2749235660 From qpzhang at openjdk.org Tue Mar 25 01:57:13 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Tue, 25 Mar 2025 01:57:13 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Mon, 24 Mar 2025 17:06:11 GMT, Magnus Ihse Bursie wrote: >> Patrick Zhang has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fixed a typo >> >> Signed-off-by: Patrick Zhang >> - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS >> >> Signed-off-by: Patrick Zhang >> - Revert the changes of adding new params to SetupNativeCompilation >> >> Signed-off-by: Patrick Zhang > > make/common/native/Flags.gmk line 125: > >> 123: endif >> 124: ifeq ($(STATIC_LIBS), true) >> 125: $1_EXTRA_CXXFLAGS += -DSTATIC_BUILD=1 > > This seems unrelated to the fix? > 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. As described in the No.3 bullet of this PR. It showed up when I tested the EXTRA_CXXFLAGS passed from outside of `SetupNativeCompilation`. It is a simple and tiny fix which may not require a separate PR I think. FYI, the failures on linux-x64-static and linux-x64-static-libs tests, captured by OpenJDK GHA Sanity Checks: https://github.com/cnqpzhang/jdk/actions/runs/13943096440. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24115#discussion_r2011164138 From syan at openjdk.org Tue Mar 25 04:10:53 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Mar 2025 04:10:53 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v5] In-Reply-To: References: Message-ID: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Redirecte stderr to /dev/null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24125/files - new: https://git.openjdk.org/jdk/pull/24125/files/ab3f5d91..f389c828 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24125/head:pull/24125 PR: https://git.openjdk.org/jdk/pull/24125 From syan at openjdk.org Tue Mar 25 04:10:53 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Mar 2025 04:10:53 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v4] In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 15:31:41 GMT, Magnus Ihse Bursie wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> fix spelling bug > > `RM` is actually defined as `rm -f` so the `-f` is not necessary. > > I'm still not very happy with this solution. It will remove any `a.out` file the user has lying around. Granted, they are normally temporary testing files, but it is highly surprising that running `configure` should remove them. To fix that, we would need to check for the existence of `a.out` prior to running the link command to set a flag if we should allow deletion or not. That would make the patch more complex. So I don't think this is the right way to go. > > Later on, we will pass `-fuse-ld=lld` to `clang`. I think the correct fix is to make sure it is always passed, from the very beginning, even when checking version strings etc. Hi @magicus Check [linker version string](https://github.com/openjdk/jdk/tree/master/make/autoconf/configure.ac#L189) is before [set linker options](https://github.com/openjdk/jdk/blob/master/make/autoconf/configure.ac#L212) in make/autoconf/configure.ac. If we want to pass `-fuse-ld=lld` to `clang` during check linker version string, this will make this PR as big project. So, I want to change the command which get the linker version like below, this will avoid generated a.out file: LINKER_VERSION_STRING=`$LINKER -Wl,-v 2>/dev/null | $HEAD -n 1` ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2750014717 From qpzhang at openjdk.org Tue Mar 25 04:32:08 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Tue, 25 Mar 2025 04:32:08 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Mon, 24 Mar 2025 18:43:42 GMT, Magnus Ihse Bursie wrote: >> Patrick Zhang has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fixed a typo >> >> Signed-off-by: Patrick Zhang >> - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS >> >> Signed-off-by: Patrick Zhang >> - Revert the changes of adding new params to SetupNativeCompilation >> >> Signed-off-by: Patrick Zhang > > make/hotspot/lib/JvmFlags.gmk line 89: > >> 87: endif >> 88: >> 89: # Hotspot currently supports only C++. To prevent compilation conflicts, > > I don't think this comments serves any purpose. It was probably a mistake to include EXTRA_CFLAGS here to begin with. After this PR, no one is going to miss it, so the comment will make no sense. I was initially unfamiliar with the building process and puzzled by why `CFLAGS` unexpectedly encompassed both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS`, until delving into all details of `JVM_CFLAGS` at a couple of m4 and gmk files. `JVM_CFLAGS` is not set up at a single place, I think necessary comments are required to warn any similar intention to append C and Objective-C only options (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html). FYI, my notes of where the `JVM_CFLAGS` got configured and used: 1). Initialization: https://github.com/openjdk/jdk/blob/b891bfa7e67c21478475642e2bfa2cdc65a3bffe/make/autoconf/flags-cflags.m4#L893 2). Updated: https://github.com/openjdk/jdk/blob/b891bfa7e67c21478475642e2bfa2cdc65a3bffe/make/hotspot/lib/JvmFlags.gmk#L89-L103 3). Passed as a parameter `CFLAGS` to `SetupJdkLibrary`, `SetupJdkNativeCompilation` , `SetupNativeCompilation` https://github.com/openjdk/jdk/blob/b891bfa7e67c21478475642e2bfa2cdc65a3bffe/make/hotspot/lib/CompileJvm.gmk#L181 4). Will take more steps for other potential changes till its arrival at the final combinations of flags: https://github.com/openjdk/jdk/blob/b891bfa7e67c21478475642e2bfa2cdc65a3bffe/make/common/native/CompileFile.gmk#L159 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24115#discussion_r2011278491 From mbaesken at openjdk.org Tue Mar 25 08:04:18 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Mar 2025 08:04:18 GMT Subject: RFR: 8351277: Remove pipewire from AIX build [v3] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 08:58:36 GMT, Matthias Baesken wrote: >> 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. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl JNI function in AIX case Thanks for the review Phil ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24009#issuecomment-2750397465 From mbaesken at openjdk.org Tue Mar 25 08:04:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Mar 2025 08:04:19 GMT Subject: Integrated: 8351277: Remove pipewire from AIX build In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025 14:52:10 GMT, Matthias Baesken wrote: > 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. This pull request has now been integrated. Changeset: 6bc48035 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/6bc480358c80b0a1a94b5ca5f4b7ff2d84ce8e37 Stats: 42 lines in 4 files changed: 36 ins; 5 del; 1 mod 8351277: Remove pipewire from AIX build Reviewed-by: ihse, prr, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/24009 From shade at openjdk.org Tue Mar 25 10:43:32 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 25 Mar 2025 10:43:32 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v3] In-Reply-To: References: Message-ID: > 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 pull request now contains five commits: - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone - 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: https://git.openjdk.org/jdk/pull/23906/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23906&range=02 Stats: 29733 lines in 25 files changed: 4 ins; 29728 del; 1 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 ihse at openjdk.org Tue Mar 25 11:00:29 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 11:00:29 GMT Subject: Integrated: 8196896: Use SYSROOT_CFLAGS in dtrace gensrc In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 15:30:58 GMT, Magnus Ihse Bursie wrote: > We are missing `$(SYSROOT_CFLAGS)` when calling `$(CPP)` directly (instead of going via `SetupNativeCompilation`). This pull request has now been integrated. Changeset: 512b9b16 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/512b9b16e009fc550afaf9aefdb912c9495ed50a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8196896: Use SYSROOT_CFLAGS in dtrace gensrc Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/24160 From ihse at openjdk.org Tue Mar 25 11:01:59 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 11:01:59 GMT Subject: Integrated: 8352618: Remove old deprecated functionality in the build system In-Reply-To: References: Message-ID: <81ikxNnr5wqJRt6A4FyyitnpbDdjUoq9wuBHV27gHeE=.ce84168f-40d7-41e7-9206-d82b87127bf4@github.com> On Fri, 21 Mar 2025 15:17:27 GMT, Magnus Ihse Bursie wrote: > It's time for some spring cleaning in the build system. These checks are for functionality that has long been deprecated, and should not be in use anymore. We should remove it to keep the code base simpler. This pull request has now been integrated. Changeset: bab93729 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/bab93729c26907dc51d15dbb5651f860f0cb58ab Stats: 64 lines in 10 files changed: 0 ins; 57 del; 7 mod 8352618: Remove old deprecated functionality in the build system Reviewed-by: erikj, kbarrett, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/24159 From ihse at openjdk.org Tue Mar 25 11:31:08 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 11:31:08 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v5] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 04:10:53 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Redirecte stderr to /dev/null Say what? Redirecting stderr to /dev/null does not trigger a.out generation, but redirecting it to stdout does? That is somehow even weirder. I don't like this. You are just trying to put band aid on, instead of addressing the core issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2750951036 From fthevenet at openjdk.org Tue Mar 25 11:32:32 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 11:32:32 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system Message-ID: OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. ------------- Commit messages: - Revert "Expand the UTIL_ARG_WITH macro to accept and check for executable files as an argument" - Use UTIL_FIXUP_EXECUTABLE to resolve provided hook path to absolute path. - Expand the UTIL_ARG_WITH macro to accept and check for executable files as an argument - Removed a ref to Windows - Make the signing hook mechanism non-windows specific. - Add build option to sign Windows native executables and libraries Changes: https://git.openjdk.org/jdk/pull/23807/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350801 Stats: 52 lines in 4 files changed: 52 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23807/head:pull/23807 PR: https://git.openjdk.org/jdk/pull/23807 From jwaters at openjdk.org Tue Mar 25 11:32:32 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 25 Mar 2025 11:32:32 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: <066K4bRBorxun-o37qc1jPDoeHk-mSg3tMnyPrRqbko=.cd8d500b-6c98-4e22-9cef-9c3340d322df@github.com> On Wed, 26 Feb 2025 18:02:53 GMT, Frederic Thevenet wrote: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. Leaving a comment here so I'm notified of any developments on this Pull Request ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2687023577 From ihse at openjdk.org Tue Mar 25 11:32:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 11:32:32 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: <066K4bRBorxun-o37qc1jPDoeHk-mSg3tMnyPrRqbko=.cd8d500b-6c98-4e22-9cef-9c3340d322df@github.com> References: <066K4bRBorxun-o37qc1jPDoeHk-mSg3tMnyPrRqbko=.cd8d500b-6c98-4e22-9cef-9c3340d322df@github.com> Message-ID: On Thu, 27 Feb 2025 06:23:17 GMT, Julian Waters wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Leaving a comment here so I'm notified of any developments on this Pull Request @TheShermanTanker FYI: You can just click the "Subscribe" button in the right-most column in the Github issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2706777881 From stuefe at openjdk.org Tue Mar 25 11:32:32 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 25 Mar 2025 11:32:32 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 18:02:53 GMT, Frederic Thevenet wrote: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. Tested on Mac OS. Works, see [build.log](https://github.com/user-attachments/files/19428633/build.log) Improvement possible: - only works with absolute path names for the signing script - signing script has to be executable ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2747784286 From fthevenet at openjdk.org Tue Mar 25 11:32:32 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 11:32:32 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 18:02:53 GMT, Frederic Thevenet wrote: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > Tested on Mac OS. Works, see [build.log](https://github.com/user-attachments/files/19428633/build.log) > > Improvement possible: > > * signing script has to be executable I've extend the `UTIL_ARG_WITH` macro with a new type to check that the provided argument is indeed an existing file with execute access under the current context, so now `configure` should fail if a non executable script is provided. > > * only works with absolute path names for the signing script This is indeed expected since the current directory is not the same at the time when the script's path is capture and when it is executed. One way to work around that would be to resolve any relative path provided to `configure` via `UTIL_ARG_WITH` to an absolute path for later use; I was thinking about using `realpath` for that but I don't know how portable this is, especially on macOS, as I've read some conflicting reports on that and don't has a mac handy to check myself (FWIW, it is available on both Cygwin and MSYS2 on Windows). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2748953536 From ihse at openjdk.org Tue Mar 25 11:32:33 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 11:32:33 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 18:02:53 GMT, Frederic Thevenet wrote: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. We have a macro `UTIL_FIXUP_PATH`, but I honestly thought it was called automatically for TYPE `file`. But maybe we don't. Just add a call to it with the name of the variable to fix, and any relative paths will be resolved and replaced with an absolute path in spec.gmk. Actually, I think there is a UTIL_FIXUP_EXECUTABLE, which takes care of adding FIXPATH and fixes any issues with `.exe` on Windows. That is the one you should use. Also, the addition of the `executable` test was good! Please re-instantiate it. I'm not sure if @tstuefe meant that it should be removed? If so, why? To be able to pass in a shell script that does not have the executable bit set? That's kind of weird. How do we even know it is a bash script then? It might just as well be a ksh or csh script, so just assuming bash would be strange. If, for some reason, you want to run a bash script without using normal shebang and x bit, then you'd have to tell configure this explicitly: `configure --with-signing-hook="bash ../my-weird-script.sh"` make/autoconf/jdk-options.m4 line 996: > 994: SIGNING_HOOK_ENABLED=true > 995: AC_SUBST(SIGNING_HOOK) > 996: AC_MSG_RESULT([yes]) Suggestion: AC_MSG_CHECKING([for signing hook]) ... AC_MSG_RESULT([$SIGNING_HOOK]) ... AC_MSG_RESULT([none]) make/common/NativeCompilation.gmk line 244: > 242: > 243: $1 += $$($1_CALL_SIGNING_HOOK) > 244: endef You can simplify this, so you get rid of `SIGNING_HOOK_ENABLED`. Also, FIXPATH is not needed after the call to `UTIL_FIXUP_EXECUTABLE`. Suggestion: define CallSigningHook ifneq ($(SIGNING_HOOK), ) # Create a rule to call post-link signing hook $1_SIGNING_OUTPUT_PREFIX := $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_call_signing_hook $1_CALL_SIGNING_HOOK := $$($1_SIGNING_OUTPUT_PREFIX).log $$($1_CALL_SIGNING_HOOK): $$($1_TARGET) $$(call LogInfo, Signing $$($1_BASENAME)) $$(call ExecuteWithLog, $$($1_SIGNING_OUTPUT_PREFIX), \ $(SIGNING_HOOK) $$($1_TARGET)) $1 += $$($1_CALL_SIGNING_HOOK) endif endef ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2749359559 PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2749361163 PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2750938087 PR Review Comment: https://git.openjdk.org/jdk/pull/23807#discussion_r2011888277 PR Review Comment: https://git.openjdk.org/jdk/pull/23807#discussion_r2011877421 From stuefe at openjdk.org Tue Mar 25 11:32:33 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 25 Mar 2025 11:32:33 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: <7Tg2Pl6eL5Sc2w6FBik8SMjOoS994ERbaTDkasI-3zs=.5d186c3d-2b0d-4205-bf14-98d115575fe1@github.com> On Mon, 24 Mar 2025 17:47:07 GMT, Frederic Thevenet wrote: > > Tested on Mac OS. Works, see [build.log](https://github.com/user-attachments/files/19428633/build.log) > > Improvement possible: > > ``` > > * signing script has to be executable > > ``` > > I've extend the `UTIL_ARG_WITH` macro with a new type to check that the provided argument is indeed an existing file with execute access under the current context, so now `configure` should fail if a non executable script is provided. Why not just call bash with the script as argument? Or is this against some policy or good style? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2750525267 From fthevenet at openjdk.org Tue Mar 25 11:32:33 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 11:32:33 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: <7Tg2Pl6eL5Sc2w6FBik8SMjOoS994ERbaTDkasI-3zs=.5d186c3d-2b0d-4205-bf14-98d115575fe1@github.com> References: <7Tg2Pl6eL5Sc2w6FBik8SMjOoS994ERbaTDkasI-3zs=.5d186c3d-2b0d-4205-bf14-98d115575fe1@github.com> Message-ID: On Tue, 25 Mar 2025 08:49:34 GMT, Thomas Stuefe wrote: > Why not just call bash with the script as argument? Or is this against some policy or good style? EDIT: I didn't want to presume that the hook would necessarily be implemented as a shell script. It seems likely that it will almost always be the case, but forcing it feels unnecessarily restrictive. Requiring the script used for the hook to be executable didn't strike me as an unreasonable requirement, although I agree it should fail as quickly as possible if it weren't, which is why I added that check at configure time. But maybe I'm missing something; are you aware of a situation where this could prove problematic or overly annoying to the user? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2750573787 From fthevenet at openjdk.org Tue Mar 25 11:32:33 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 11:32:33 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 20:49:23 GMT, Magnus Ihse Bursie wrote: > Actually, I think there is a UTIL_FIXUP_EXECUTABLE, which takes care of adding FIXPATH and fixes any issues with `.exe` on Windows. That is the one you should use. Thanks @magicus. I have reverted my changes in favour of using `UTIL_FIXUP_EXECUTABLE` instead. > Also, the addition of the `executable` test was good! Please re-instantiate it. > > I'm not sure if @tstuefe meant that it should be removed? If so, why? To be able to pass in a shell script that does not have the executable bit set? That's kind of weird. How do we even know it is a bash script then? It might just as well be a ksh or csh script, so just assuming bash would be strange. I removed the check because I noticed that `UTIL_FIXUP_EXECUTABLE` already performs such a check and so it was redundant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2750792636 PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2750945783 From ihse at openjdk.org Tue Mar 25 11:35:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 11:35:11 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v5] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 04:10:53 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Redirecte stderr to /dev/null And no, passing `-fuse-ld=lld` to the linker at all time does not make this a big PR. Try something like this (untested, but should work): diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4 index c240b9098bc..315017c48c4 100644 --- a/make/autoconf/toolchain.m4 +++ b/make/autoconf/toolchain.m4 @@ -620,6 +620,11 @@ AC_DEFUN_ONCE([TOOLCHAIN_DETECT_TOOLCHAIN_CORE], # All other toolchains use the compiler to link. LD="$CC" LDCXX="$CXX" + # Force use of lld, since that is what we expect when setting flags later on + if test "x$TOOLCHAIN_TYPE" = xclang; then + LD="$LD -fuse-ld=lld" + LDCXX="$LDCXX -fuse-ld=lld" + fi fi AC_SUBST(LD) # FIXME: it should be CXXLD, according to standard (cf CXXCPP) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2750960047 From ihse at openjdk.org Tue Mar 25 11:39:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 11:39:11 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 11:26:09 GMT, Frederic Thevenet wrote: > I removed the check because I noticed that UTIL_FIXUP_EXECUTABLE already performs such a check and so it was redundant. I see. The benefit of your solution was that the error message is tied to the configure argument and is more clear to the user. The check in UTIL_FIXUP_EXECUTABLE is more of a fallback insurance, and if it is triggered, the error message written might not be clear to the user what went wrong. So I still think it serves a purpose, to verify incoming arguments up-front, and it fit very nicely into the UTIL_ARG_WITH framework. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2750968681 From dnsimon at openjdk.org Tue Mar 25 12:13:01 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 25 Mar 2025 12:13:01 GMT Subject: RFR: 8352645: Add tool support to check order of includes Message-ID: This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). This script can also update files with unsorted includes. The second commit in this PR shows the result of running: python3 ./bin/sort_includes.py ./src/hotspot To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. ------------- Commit messages: - do not reorder includes in immediate_aarch64.cpp - do not reorder includes in systemMemoryBarrier_windows.cpp - sort include statements in hotspot - added tool to sort includes Changes: https://git.openjdk.org/jdk/pull/24180/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352645 Stats: 1489 lines in 437 files changed: 799 ins; 653 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/24180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24180/head:pull/24180 PR: https://git.openjdk.org/jdk/pull/24180 From dnsimon at openjdk.org Tue Mar 25 12:13:03 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 25 Mar 2025 12:13:03 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote: > This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 26: > 24: */ > 25: > 26: #include Moving these sys includes causes a build failure: https://github.com/dougxc/jdk/actions/runs/14054959680/job/39352322113#step:12:537 In file included from /home/runner/work/jdk/jdk/src/hotspot/cpu/aarch64/immediate_aarch64.cpp:26: /home/runner/work/jdk/jdk/src/hotspot/cpu/aarch64/immediate_aarch64.hpp:49:1: error: ?uint64_t? does not name a type; did you mean ?u_int64_t?? 49 | uint64_t logical_immediate_for_encoding(uint32_t encoding); | ^~~~~~~~ | u_int64_t The question is whether they should not be re-ordered or whether `immediate_aarch64.hpp` should add the sys includes it apparently needs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2011659864 From dnsimon at openjdk.org Tue Mar 25 12:13:03 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 25 Mar 2025 12:13:03 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: <75t-g0hbKrY5JugITjnd8Vhxi86fuVR8g1_KXyLS4G8=.0acd8ca4-67f9-4723-9735-399d03a848bf@github.com> On Tue, 25 Mar 2025 09:16:15 GMT, Doug Simon wrote: >> This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). >> This script can also update files with unsorted includes. The second commit in this PR shows the result of running: >> >> python3 ./bin/sort_includes.py ./src/hotspot >> >> To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. >> >> Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. > > src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 26: > >> 24: */ >> 25: >> 26: #include > > Moving these sys includes causes a build failure: https://github.com/dougxc/jdk/actions/runs/14054959680/job/39352322113#step:12:537 > > In file included from /home/runner/work/jdk/jdk/src/hotspot/cpu/aarch64/immediate_aarch64.cpp:26: > /home/runner/work/jdk/jdk/src/hotspot/cpu/aarch64/immediate_aarch64.hpp:49:1: error: ?uint64_t? does not name a type; did you mean ?u_int64_t?? > 49 | uint64_t logical_immediate_for_encoding(uint32_t encoding); > | ^~~~~~~~ > | u_int64_t > > The question is whether they should not be re-ordered or whether `immediate_aarch64.hpp` should add the sys includes it apparently needs. I pushed a commit that prevents the re-ordering: https://github.com/openjdk/jdk/pull/24180/commits/c0f202d2a7e7b8788719fe8cd2a4c7a095ecd3bb ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2011951143 From syan at openjdk.org Tue Mar 25 12:20:33 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Mar 2025 12:20:33 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v5] In-Reply-To: References: Message-ID: <6QFlCgW-yactbTWr9FdOf8aDY7ToqdrfBHPoqFUB84Q=.6f507f47-28f1-4011-aee2-ebde3662c9d0@github.com> On Tue, 25 Mar 2025 11:32:17 GMT, Magnus Ihse Bursie wrote: > And no, passing `-fuse-ld=lld` to the linker at all time does not make this a big PR. Try something like this (untested, but should work): Okey, this change works. I was mistakenly though we should use `BASIC_LDFLAGS` in `FLAGS_SETUP_LDFLAGS_HELPER`. PR has been updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2751067301 From syan at openjdk.org Tue Mar 25 12:20:33 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Mar 2025 12:20:33 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v6] In-Reply-To: References: Message-ID: <1G-OvdNkWuI0b_ZcUkJuIVJtmZcrM9tRSQYrOHqhtDc=.ecc0c165-95e0-4e0f-8ee7-aee696570612@github.com> > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR add a command to remove the extra a.out file. No risk. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Force use of lld when toolchain is clang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24125/files - new: https://git.openjdk.org/jdk/pull/24125/files/f389c828..78167398 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=04-05 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24125/head:pull/24125 PR: https://git.openjdk.org/jdk/pull/24125 From syan at openjdk.org Tue Mar 25 12:40:42 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Mar 2025 12:40:42 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v7] In-Reply-To: References: Message-ID: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR force use of lld when toolchain type is clang. Change has been verified locally. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Force use of lld when build os is not macosx ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24125/files - new: https://git.openjdk.org/jdk/pull/24125/files/78167398..d4796781 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24125&range=05-06 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24125/head:pull/24125 PR: https://git.openjdk.org/jdk/pull/24125 From stuefe at openjdk.org Tue Mar 25 12:46:17 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 25 Mar 2025 12:46:17 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 11:36:01 GMT, Magnus Ihse Bursie wrote: >>> Also, the addition of the `executable` test was good! Please re-instantiate it. >>> >>> I'm not sure if @tstuefe meant that it should be removed? If so, why? To be able to pass in a shell script that does not have the executable bit set? That's kind of weird. How do we even know it is a bash script then? It might just as well be a ksh or csh script, so just assuming bash would be strange. >> >> I removed the check because I noticed that `UTIL_FIXUP_EXECUTABLE` already performs such a check and so it was redundant. > >> I removed the check because I noticed that UTIL_FIXUP_EXECUTABLE already performs such a check and so it was redundant. > > I see. > > The benefit of your solution was that the error message is tied to the configure argument and is more clear to the user. The check in UTIL_FIXUP_EXECUTABLE is more of a fallback insurance, and if it is triggered, the error message written might not be clear to the user what went wrong. So I still think it serves a purpose, to verify incoming arguments up-front, and it fit very nicely into the UTIL_ARG_WITH framework. @magicus is the leading build engineer. Please feel free to ignore anything I suggest if he argues against it :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2751136369 From shade at openjdk.org Tue Mar 25 13:29:30 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 25 Mar 2025 13:29:30 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v3] In-Reply-To: References: Message-ID: <6aH6pqUjOOhfguuCXDjuRPNpieiu2rzJ7XxnTFQ2D4w=.fe2d0cd3-181d-4189-a3cb-6637bf85d89c@github.com> On Tue, 25 Mar 2025 10:43:32 GMT, Aleksey Shipilev 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 pull request now contains five commits: > > - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone > - 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 is now targeted to JDK 25. I remerged from master, resolved a few easy conflicts in files that are removed by this PR anyway, and did some light testing. Everything looks green. I only miss the re-review after the merge. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2751258762 From fthevenet at openjdk.org Tue Mar 25 14:17:51 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 14:17:51 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v2] In-Reply-To: References: Message-ID: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. Frederic Thevenet has updated the pull request incrementally with two additional commits since the last revision: - Simplified CallSigningHook logic - Reapply "Expand the UTIL_ARG_WITH macro to accept and check for executable files as an argument" This reverts commit ca7ddc6ba337e723a80e4794633b073dda5c0951. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23807/files - new: https://git.openjdk.org/jdk/pull/23807/files/ca7ddc6b..b7110270 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=00-01 Stats: 32 lines in 3 files changed: 8 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/23807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23807/head:pull/23807 PR: https://git.openjdk.org/jdk/pull/23807 From fthevenet at openjdk.org Tue Mar 25 14:17:51 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 14:17:51 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v2] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 11:24:51 GMT, Magnus Ihse Bursie wrote: >> Frederic Thevenet has updated the pull request incrementally with two additional commits since the last revision: >> >> - Simplified CallSigningHook logic >> - Reapply "Expand the UTIL_ARG_WITH macro to accept and check for executable files as an argument" >> >> This reverts commit ca7ddc6ba337e723a80e4794633b073dda5c0951. > > make/autoconf/jdk-options.m4 line 996: > >> 994: SIGNING_HOOK_ENABLED=true >> 995: AC_SUBST(SIGNING_HOOK) >> 996: AC_MSG_RESULT([yes]) > > Suggestion: > > > AC_MSG_CHECKING([for signing hook]) > > ... > > AC_MSG_RESULT([$SIGNING_HOOK]) > > ... > > AC_MSG_RESULT([none]) done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23807#discussion_r2012206798 From matthias.baesken at sap.com Tue Mar 25 14:23:57 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 25 Mar 2025 14:23:57 +0000 Subject: broken dependencies when doing make all ? Message-ID: Hello, I was running on Linux into this issue today : make all Building target 'all' in configuration '/builddir' gmake[3]: *** No rule to make target '/builddir/support/interim-image/bin/java', needed by '/builddir/support/link_opt/classlist'. Stop. gmake[2]: *** [make/Main.gmk:649: generate-link-opt-data] Error 2 gmake[2]: *** Waiting for unfinished jobs.... ERROR: Build failed for target 'all' in configuration '/builddir' (exit code 2) No indication of failed target found. HELP: Try searching the build log for '] Error'. HELP: Run 'make doctor' to diagnose build problems. make[1]: *** [main] Error 2 make: *** [all] Error 2 Any idea what?s going wrong ? Is there maybe some issue with the dependencies of the make ? (it is an incremental make and my understanding was that the dependencies of the make will lead to regeneration of such missing files ?) Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From fthevenet at openjdk.org Tue Mar 25 14:26:46 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 14:26:46 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v3] In-Reply-To: References: Message-ID: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: SIGNING_HOOK_ENABLED is no longer used ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23807/files - new: https://git.openjdk.org/jdk/pull/23807/files/b7110270..35e1bb08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23807/head:pull/23807 PR: https://git.openjdk.org/jdk/pull/23807 From ihse at openjdk.org Tue Mar 25 14:55:17 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 14:55:17 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: <75t-g0hbKrY5JugITjnd8Vhxi86fuVR8g1_KXyLS4G8=.0acd8ca4-67f9-4723-9735-399d03a848bf@github.com> References: <75t-g0hbKrY5JugITjnd8Vhxi86fuVR8g1_KXyLS4G8=.0acd8ca4-67f9-4723-9735-399d03a848bf@github.com> Message-ID: On Tue, 25 Mar 2025 12:06:42 GMT, Doug Simon wrote: >> src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 26: >> >>> 24: */ >>> 25: >>> 26: #include >> >> Moving these sys includes causes a build failure: https://github.com/dougxc/jdk/actions/runs/14054959680/job/39352322113#step:12:537 >> >> In file included from /home/runner/work/jdk/jdk/src/hotspot/cpu/aarch64/immediate_aarch64.cpp:26: >> /home/runner/work/jdk/jdk/src/hotspot/cpu/aarch64/immediate_aarch64.hpp:49:1: error: ?uint64_t? does not name a type; did you mean ?u_int64_t?? >> 49 | uint64_t logical_immediate_for_encoding(uint32_t encoding); >> | ^~~~~~~~ >> | u_int64_t >> >> The question is whether they should not be re-ordered or whether `immediate_aarch64.hpp` should add the sys includes it apparently needs. > > I pushed a commit that prevents the re-ordering: https://github.com/openjdk/jdk/pull/24180/commits/c0f202d2a7e7b8788719fe8cd2a4c7a095ecd3bb My gut reaction is that header files should be self-sustaining, that is if they need some external header files, these should be included by the header file itself. But that is up to the hotspot folks to decide. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012289902 From ihse at openjdk.org Tue Mar 25 14:59:28 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 14:59:28 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: <-LIpZBv5VsK3GyY-zNar1x2BU30LhdlCnQalEigLAsA=.67180c55-a332-4219-8056-3549bd45c200@github.com> On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote: > This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. Interesting! Thank you for creating automation for keeping the code up to the code standard. You wrote the script using python. We have intentionally not been using python before, to avoid dragging in yet another dependency. I realize this is a free-standing script and a python dependency is still not required for building, but I still would like to see it avoided. Did you consider writing the tool in Java? Or rather, could you be convinced to convert it to Java? With the source code launch mechanism, it is just as simple to run as a python script. Also, there is some kind of optics about it as well, where we actually use Java for developing the JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24180#issuecomment-2751551897 From ihse at openjdk.org Tue Mar 25 15:02:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 15:02:18 GMT Subject: RFR: 8352692: Add support for extra jlink options In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 10:37:10 GMT, Severin Gehwolf wrote: > Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. > > Testing: > - [x] GHA > - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. > > Thoughts? make/autoconf/jdk-options.m4 line 638: > 636: # Extra jlink options to be (optionally) passed to the JDK build > 637: # > 638: AC_ARG_WITH(extra-jlink-flags, [AS_HELP_STRING([--with-extra-jlink-flags], Please use `UTIL_ARG_WITH` for new flags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24188#discussion_r2012305560 From mdoerr at openjdk.org Tue Mar 25 15:22:22 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 25 Mar 2025 15:22:22 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v3] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 10:43:32 GMT, Aleksey Shipilev 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 pull request now contains five commits: > > - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone > - 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 LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2714187303 From ihse at openjdk.org Tue Mar 25 15:27:14 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 15:27:14 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v3] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 10:43:32 GMT, Aleksey Shipilev 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 pull request now contains five commits: > > - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone > - 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-2714207496 From ihse at openjdk.org Tue Mar 25 15:33:20 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 15:33:20 GMT Subject: RFR: 8352481: Extra a.out generated after configure with clang [v7] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 12:40:42 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR force use of lld when toolchain type is clang. Change has been verified locally. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Force use of lld when build os is not macosx Marked as reviewed by ihse (Reviewer). I think the fix looks good now, but the bug title do no longer match what this is actually about. I updated the title in JBS, but I am not allowed to change the PR title. The easiest way for you to fix this is to just rename the PR to `8352481` and then Skara bots will automatically put in the JBS title. ------------- PR Review: https://git.openjdk.org/jdk/pull/24125#pullrequestreview-2714227636 PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2751663454 From ihse at openjdk.org Tue Mar 25 15:37:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 15:37:18 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v3] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 14:26:46 GMT, Frederic Thevenet wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > SIGNING_HOOK_ENABLED is no longer used make/autoconf/jdk-options.m4 line 997: > 995: else > 996: AC_MSG_RESULT([none]) > 997: fi Sorry, I noticed one more thing. `AC_SUBST` will need to prepare the `SIGNING_HOOK` replacement in spec.gmk, regardless of if it is empty or set to a value. Due to the limitations of m4 expansion and how autoconf is implemented, the effect of `AC_SUBST` will be carried out regardless of the test in the if block. So the code above will actually work, but it is misleading, since things are written inside the if block that will be executed unconditionally. So please follow the pattern we have elsewhere and move AC_SUBST to the end: Suggestion: AC_MSG_CHECKING([for signing hook]) if test "x$SIGNING_HOOK" != x; then UTIL_FIXUP_EXECUTABLE(SIGNING_HOOK) AC_MSG_RESULT([$SIGNING_HOOK]) else AC_MSG_RESULT([none]) fi AC_SUBST(SIGNING_HOOK) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23807#discussion_r2012385131 From magnus.ihse.bursie at oracle.com Tue Mar 25 15:40:13 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 16:40:13 +0100 Subject: broken dependencies when doing make all ? In-Reply-To: References: Message-ID: <3ea5f450-0422-4113-a61e-403d99492d31@oracle.com> On 2025-03-25 15:23, Baesken, Matthias wrote: > HELP: Try searching the build log for '] Error'. > > HELP: Run 'make doctor' to diagnose build problems. > Did you try to run "make doctor"? > Any idea what?s going wrong ? ?Is there maybe some issue with the > dependencies of the make ? > > (it is an incremental make and my understanding was that? the > dependencies of the make will? lead to regeneration of such missing > files ?) > Normally, incremental builds work fine, but they are not 100% proof. In particular, "make reconfigure" can cause situations that an incremental build cannot properly resolve. (This is printed as a warning if you modify an existing configuration, with a recommendation to start by cleaning the build for a guaranteed successes, but it works most of the time, so people tend to ignore it...) /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From fthevenet at openjdk.org Tue Mar 25 15:50:36 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 15:50:36 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v4] In-Reply-To: References: Message-ID: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Update make/autoconf/jdk-options.m4 Co-authored-by: Magnus Ihse Bursie ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23807/files - new: https://git.openjdk.org/jdk/pull/23807/files/35e1bb08..4c548a8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23807/head:pull/23807 PR: https://git.openjdk.org/jdk/pull/23807 From magnus.ihse.bursie at oracle.com Tue Mar 25 15:52:29 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 16:52:29 +0100 Subject: javac stack overflow on loongson3 with zero variant In-Reply-To: <4641863.LvFx2qVVIh@xtex1> References: <4641863.LvFx2qVVIh@xtex1> Message-ID: <9ba55b96-8832-48f6-be47-52b114347928@oracle.com> On 2025-03-22 01:55, Bingwu Zhang wrote: > Recently when packaging OpenJDK 24-ga for AOSC OS, I hit an compilation error > on loongson3 (which is a variant of mips64), saying that javac is running out > of stack space: > >> java.lang.StackOverflowError >> at jdk.compiler.interim/ >> [...] > What should I try next? Is this a bug or a even larger stack is required? Is this reproducible? Did it started happening recently? If so, can you bisect to which commit introduced the problem? From your configure command line, it does not look like you are cross-compiling. Can you confirm that you are actually building natively on mips64? (That's kind of exciting, I've never heard about it before :-)). If you try running without the javac server, does it change anything? ("configure --disable-javac-server") The stack trace in your log is extremely long. While it does not look like an infinite recursive call, it looks suspicious. It does not seem reasonable to me that javac should get a tree that deep in a normal operation. Is the default stack size different on mips64 than other platforms? Maybe that default value should be changed if so. I can't say straight out of my head what's the correct way to pass an -Xss argument to the interim compiler, but if you want to try it out, you can, as a hack, add it to INTERIM_LANGTOOLS_ARGS in spec.gmk.template. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at openjdk.org Tue Mar 25 15:54:15 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 25 Mar 2025 15:54:15 GMT Subject: RFR: 8352692: Add support for extra jlink options In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 14:59:13 GMT, Magnus Ihse Bursie wrote: >> Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. >> >> Testing: >> - [x] GHA >> - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. >> >> Thoughts? > > make/autoconf/jdk-options.m4 line 638: > >> 636: # Extra jlink options to be (optionally) passed to the JDK build >> 637: # >> 638: AC_ARG_WITH(extra-jlink-flags, [AS_HELP_STRING([--with-extra-jlink-flags], > > Please use `UTIL_ARG_WITH` for new flags. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24188#discussion_r2012419121 From dnsimon at openjdk.org Tue Mar 25 15:54:23 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 25 Mar 2025 15:54:23 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: <-LIpZBv5VsK3GyY-zNar1x2BU30LhdlCnQalEigLAsA=.67180c55-a332-4219-8056-3549bd45c200@github.com> References: <-LIpZBv5VsK3GyY-zNar1x2BU30LhdlCnQalEigLAsA=.67180c55-a332-4219-8056-3549bd45c200@github.com> Message-ID: On Tue, 25 Mar 2025 14:56:27 GMT, Magnus Ihse Bursie wrote: > Did you consider writing the tool in Java? Or rather, could you be convinced to convert it to Java? With the source code launch mechanism, it is just as simple to run as a python script. Also, there is some kind of optics about it as well, where we actually use Java for developing the JDK. Good idea. I'll give it a go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24180#issuecomment-2751733004 From matthias.baesken at sap.com Tue Mar 25 15:57:08 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 25 Mar 2025 15:57:08 +0000 Subject: broken dependencies when doing make all ? In-Reply-To: <3ea5f450-0422-4113-a61e-403d99492d31@oracle.com> References: <3ea5f450-0422-4113-a61e-403d99492d31@oracle.com> Message-ID: > Did you try to run "make doctor"? No . (I have to confess I deleted some stuff from the builddir before) . >Normally, incremental builds work fine, but they are not 100% proof. In particular, "make reconfigure" can cause situations that an incremental build >cannot properly resolve. (This is printed as a warning if you modify an existing configuration, with a recommendation to start by cleaning the build for a >guaranteed successes, but it works most of the time, so people tend to ignore it...) The mentioned ?make reconfigure? was not done, but maybe the deletion caused trouble . Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihse at openjdk.org Tue Mar 25 15:57:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 15:57:09 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v4] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 15:50:36 GMT, Frederic Thevenet wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Update make/autoconf/jdk-options.m4 > > Co-authored-by: Magnus Ihse Bursie This looks excellent now! Thanks for working with us to get your contribution in shape. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23807#pullrequestreview-2714316134 From magnus.ihse.bursie at oracle.com Tue Mar 25 15:58:10 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 16:58:10 +0100 Subject: broken dependencies when doing make all ? In-Reply-To: References: <3ea5f450-0422-4113-a61e-403d99492d31@oracle.com> Message-ID: <786e1e3f-e3a8-484b-a747-125597e22303@oracle.com> On 2025-03-25 16:57, Baesken, Matthias wrote: > > Did you try to run "make doctor"? > > No . > > (I have to confess I deleted some stuff from the builddir before) . > > >Normally, incremental builds work fine, but they are not 100% proof. > In particular, "make reconfigure" can cause situations that an > incremental build >cannot properly resolve. (This is printed as a > warning if you modify an existing configuration, with a recommendation > to start by cleaning the build for a >guaranteed successes, but it > works most of the time, so people tend to ignore it...) > > The mentioned ?make reconfigure? was not done,? but? maybe the > deletion caused trouble . > Have you tried doing a "make clean" to see if it resolves the issue? /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Tue Mar 25 16:00:21 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 25 Mar 2025 16:00:21 +0000 Subject: broken dependencies when doing make all ? In-Reply-To: <786e1e3f-e3a8-484b-a747-125597e22303@oracle.com> References: <3ea5f450-0422-4113-a61e-403d99492d31@oracle.com> <786e1e3f-e3a8-484b-a747-125597e22303@oracle.com> Message-ID: >Have you tried doing a "make clean" to see if it resolves the issue? I did an ?rm -rf? and full rebuild ? ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fthevenet at openjdk.org Tue Mar 25 16:05:13 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 16:05:13 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v4] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 15:50:36 GMT, Frederic Thevenet wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Update make/autoconf/jdk-options.m4 > > Co-authored-by: Magnus Ihse Bursie Thank you for your thorough review and precious advice! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2751768063 From magnus.ihse.bursie at oracle.com Tue Mar 25 16:31:02 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 25 Mar 2025 17:31:02 +0100 Subject: broken dependencies when doing make all ? In-Reply-To: References: <3ea5f450-0422-4113-a61e-403d99492d31@oracle.com> <786e1e3f-e3a8-484b-a747-125597e22303@oracle.com> Message-ID: On 2025-03-25 17:00, Baesken, Matthias wrote: > >Have you tried doing a "make clean" to see if it resolves the issue? > > I did an ?rm -rf? and full rebuild ? ! > And the problem still persisted..? /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Tue Mar 25 16:34:04 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 25 Mar 2025 16:34:04 +0000 Subject: broken dependencies when doing make all ? In-Reply-To: References: <3ea5f450-0422-4113-a61e-403d99492d31@oracle.com> <786e1e3f-e3a8-484b-a747-125597e22303@oracle.com> Message-ID: >And the problem still persisted..? No, just the incremental build was bad ; after rm -rf and full rebuild everything was fine . Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Tue Mar 25 16:36:31 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 25 Mar 2025 16:36:31 GMT Subject: RFR: 8352481: Enforce the use of lld with clang [v7] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 12:40:42 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR force use of lld when toolchain type is clang. Change has been verified locally. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Force use of lld when build os is not macosx Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24125#pullrequestreview-2714440035 From erik.joelsson at oracle.com Tue Mar 25 17:06:10 2025 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 25 Mar 2025 10:06:10 -0700 Subject: broken dependencies when doing make all ? In-Reply-To: References: <3ea5f450-0422-4113-a61e-403d99492d31@oracle.com> Message-ID: On 3/25/25 08:57, Baesken, Matthias wrote: > > > Did you try to run "make doctor"? > > No . > > (I have to confess I deleted some stuff from the builddir before) . > If you manually delete stuff from the builddir, you cannot expect incremental builds to work unless you know exactly what to delete. Make does track dependencies, but that only works really well when every file in the output is known and can be declared to be the result of a complete set of prerequisites (e.g. foo.c -> foo.o). Our build is far from this ideal. We have plenty of build steps where the makefiles cannot predict all the files that will be generated by a rule (e.g. Foo.java -> Foo.class, Foo$1.class, Foo$Internal.class etc). To work around this we use "touch files" or pick a particular known file in the output to declare the rule around. As long as files in the builddir are only deleted together with the appropriate touch files or as a group including the chosen target file, incremental builds should work. Knowing exactly how these groups are composited is hard however, so my recommendation is to stick to the existing clean targets unless you know for sure what to delete. /Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Tue Mar 25 17:25:18 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 25 Mar 2025 17:25:18 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v4] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 15:50:36 GMT, Frederic Thevenet wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Update make/autoconf/jdk-options.m4 > > Co-authored-by: Magnus Ihse Bursie Using the log file from ExecuteWithLog as the recipe target to work around changing/signing the actual target file in place is an interesting choice, but I think it will work. Have you tried incremental builds thoroughly? ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23807#pullrequestreview-2714587341 From sgehwolf at openjdk.org Tue Mar 25 18:30:30 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 25 Mar 2025 18:30:30 GMT Subject: RFR: 8352692: Add support for extra jlink options [v2] In-Reply-To: References: Message-ID: > Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. > > Testing: > - [x] GHA > - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Use UTIL_ARG_WITH over AC_ARG_WITH ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24188/files - new: https://git.openjdk.org/jdk/pull/24188/files/bfe2ecb3..7bf97d65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24188&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24188&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24188/head:pull/24188 PR: https://git.openjdk.org/jdk/pull/24188 From sgehwolf at openjdk.org Tue Mar 25 18:30:30 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 25 Mar 2025 18:30:30 GMT Subject: RFR: 8352692: Add support for extra jlink options [v2] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 15:51:02 GMT, Severin Gehwolf wrote: >> make/autoconf/jdk-options.m4 line 638: >> >>> 636: # Extra jlink options to be (optionally) passed to the JDK build >>> 637: # >>> 638: AC_ARG_WITH(extra-jlink-flags, [AS_HELP_STRING([--with-extra-jlink-flags], >> >> Please use `UTIL_ARG_WITH` for new flags. > > OK. Done in https://github.com/openjdk/jdk/pull/24188/commits/7bf97d65304d5bebb767af54fcde12a7b604b6b0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24188#discussion_r2012719509 From stefank at openjdk.org Tue Mar 25 19:13:12 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 25 Mar 2025 19:13:12 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: <75t-g0hbKrY5JugITjnd8Vhxi86fuVR8g1_KXyLS4G8=.0acd8ca4-67f9-4723-9735-399d03a848bf@github.com> Message-ID: On Tue, 25 Mar 2025 14:52:56 GMT, Magnus Ihse Bursie wrote: >> I pushed a commit that prevents the re-ordering: https://github.com/openjdk/jdk/pull/24180/commits/c0f202d2a7e7b8788719fe8cd2a4c7a095ecd3bb > > My gut reaction is that header files should be self-sustaining, that is if they need some external header files, these should be included by the header file itself. But that is up to the hotspot folks to decide. Magnus is correct. Though, it's really hard to maintain that unless you have a tool to help out with that, so we tend to fix this whenever we find include issues. For uin64_t (and friends) we include globalDefinitions.hpp instead of including the system headers directly. (FWIW, this file also has its own style for the includes guards. This should probably be updated to follow the other include guards we use in HotSpot, but not in this PR) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012780477 From fthevenet at openjdk.org Tue Mar 25 20:19:19 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 25 Mar 2025 20:19:19 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v4] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 17:22:07 GMT, Erik Joelsson wrote: > Using the log file from ExecuteWithLog as the recipe target to work around changing/signing the actual target file in place is an interesting choice, but I think it will work. Have you tried incremental builds thoroughly? Hmm... If think you're right to be suspicious about this; I just realized this approach has a pretty big flaw: in the event of a failure occurring in the script, `make` will delete the file used as the target, which in this case is bad since not only the job failed, but you've just lost the log file that could have helped you understand why! To be fair, what's in the `ExecuteWithLog` file should also be present in `build.log`, but it will mixed up with everything else and potentially a pain to piece back together. I'm leaning toward reverting to my initial idea, which was to add the command that calls the script as part of the linking recipe. I decided to extract it in its own to avoid duplication, since linking for Windows and macOS/Linux is split across two source files, but I'm thinking that might not be justified, since it's only a couple of lines (see https://github.com/fthevenet/jdk/commit/2afcf05edbf8498a5f289a6247506b5a284e2be9 to get of sense of the diff). This also has the benefit of putting to rest any worries w.r.t. incremental builds, I think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2752415817 From stefank at openjdk.org Tue Mar 25 20:43:26 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 25 Mar 2025 20:43:26 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote: > This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. Thanks for taking the time to write this tool! I haven't reviewed the script, but I looked over the resulting changes to the includes and have commented on places where I see a discrepancy between what the tool generated and what I would have changed the code to be. Some of my comments are things that we would be great if the tool could fix, but I also think that we could be pragmatic and just fix these manually. OTOH, if we need to do a bunch of manual adjustment then it might not be ready to be included in jcheck. I think it depends on how this tool is going to be used. If it is going to be an authoritative tool for our includes, then it probably needs to handle some of the cases that I listed. With that said, even if there are some back-and-forth discussion about the tool, I think pushing the sort-order fixes by themselves would be worthwhile in it self. Thanks again! src/hotspot/cpu/aarch64/foreignGlobals_aarch64.cpp line 32: > 30: #include "prims/vmstorage.hpp" > 31: #include "runtime/jniHandles.hpp" > 32: #include "runtime/jniHandles.inline.hpp" I know that you didn't introduce this, but I wanted to point out that the convention we are using is to not include the .hpp file if the associated .inline.hpp is included. src/hotspot/cpu/arm/gc/g1/g1BarrierSetAssembler_arm.cpp line 32: > 30: #include "gc/g1/g1HeapRegion.hpp" > 31: #include "gc/g1/g1ThreadLocalData.hpp" > 32: #include "gc/g1/g1ThreadLocalData.hpp" Not your tools fault, but in case you also want to handle this case, we have two includes of the same file here. src/hotspot/cpu/ppc/vm_version_ppc.cpp line 44: > 42: #if defined(_AIX) > 43: #include "os_aix.hpp" > 44: For this file I would have expected the separation of system includes be done as follows: #include "utilities/powerOfTwo.hpp" #if defined(_AIX) #include "os_aix.hpp" #endif #include #if defined(_AIX) #include #endif src/hotspot/os/aix/os_aix.cpp line 98: > 96: #include > 97: #include > 98: #include FWIW, it would be interesting to hear if the AIX maintainers really need the define in the middle of the system includes ... src/hotspot/os/aix/porting_aix.cpp line 30: > 28: #define __XCOFF64__ > 29: #include > 30: This blank line should probably be left in place. (It would also be nice to have a blankline between line 23 and 24, but not your tool's job to fix that) src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 34: > 32: #include "utilities/powerOfTwo.hpp" > 33: > 34: One too many blanklines. src/hotspot/os/linux/osContainer_linux.cpp line 34: > 32: #include > 33: #include > 34: #include There are too blank lines after the includes. (In case you want to enhance your tool to also clean that out) src/hotspot/os/posix/safefetch_sigjmp.cpp line 36: > 34: // For SafeFetch we need POSIX TLS and sigsetjmp/longjmp. > 35: #include > 36: #include Missing blankline after this include. (In case you want to add support for this cleanup in your tool) src/hotspot/os/windows/os_windows.cpp line 108: > 106: #include // For os::dll_address_to_function_name > 107: // for enumerating dll libraries > 108: #include The include moved, but the comment was left, so the comment now refers to the wrong include (I think). FWIW, I tend to remove these comments about why they are included because they become obsolete if you start to use more things from the headers. src/hotspot/os/windows/symbolengine.cpp line 31: > 29: #include "windbghelp.hpp" > 30: > 31: #include This left two consecutive blanklines. src/hotspot/os/windows/systemMemoryBarrier_windows.cpp line 27: > 25: #include "systemMemoryBarrier_windows.hpp" > 26: > 27: #include I'm a little curious about why this was needed, but just a little bit ... src/hotspot/share/adlc/archDesc.cpp line 27: > 25: > 26: // archDesc.cpp - Internal format for architecture definition > 27: #include // do not reorder I *guess* that this has to do with the assert define. I think Kim has another workaround for that. src/hotspot/share/cds/archiveBuilder.cpp line 51: > 49: #include "memory/allStatic.hpp" > 50: #include "memory/memRegion.hpp" > 51: #include "memory/memoryReserver.hpp" I think this can be argued is a bug. In previous discussion we (or, at least I) have argued that the sort order should be case-insensitive. src/hotspot/share/compiler/compilationFailureInfo.cpp line 37: > 35: #ifdef COMPILER2 > 36: #include "opto/compile.hpp" > 37: #include "opto/node.hpp" Here the entire: #ifdef COMPILER2 #include "opto/compile.hpp" #include "opto/node.hpp" #endif block should be last. I don't know if your tool should try to fix this. src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp line 40: > 38: #include "utilities/globalDefinitions.hpp" > 39: > 40: Stray extra blankline src/hotspot/share/gc/shared/gcConfiguration.cpp line 27: > 25: #include "gc/shared/gcArguments.hpp" > 26: #include "gc/shared/gcConfiguration.hpp" > 27: #include "gc/shared/gc_globals.hpp" I think the manual sorting order placed _ before letter. Your tool undos that. I think this is OK, but I wanted to point this out so that this is done intentionally. src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 37: > 35: #include "logging/log.hpp" > 36: > 37: Stray extra blankline src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 33: > 31: #include "utilities/quickSort.hpp" > 32: > 33: Stray extra blankline src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp line 35: > 33: #include "utilities/quickSort.hpp" > 34: > 35: Stray extra blankline src/hotspot/share/gc/shenandoah/shenandoahController.cpp line 30: > 28: #include "gc/shenandoah/shenandoahHeap.hpp" > 29: #include "gc/shenandoah/shenandoahHeapRegion.inline.hpp" > 30: #include "shenandoahCollectorPolicy.hpp" (I think it would be nice if Shenandoah maintainers added the gc/shenandoah/ to this include) src/hotspot/share/gc/shenandoah/shenandoahController.cpp line 31: > 29: #include "gc/shenandoah/shenandoahHeapRegion.inline.hpp" > 30: #include "shenandoahCollectorPolicy.hpp" > 31: Stray extra blankline src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 43: > 41: #include "utilities/quickSort.hpp" > 42: > 43: Stray extra blankline (there are probably more, but I'll skip this) src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 81: > 79: #include "gc/shenandoah/shenandoahYoungGeneration.hpp" > 80: > 81: This section has three blanklines, but there should be none if this is to follow the rest of the HotSpot include style. src/hotspot/share/opto/output.cpp line 39: > 37: #include "opto/block.hpp" > 38: #include "opto/c2_MacroAssembler.hpp" > 39: #include "opto/c2compiler.hpp" Hmm. #include "opto/c2_MacroAssembler.hpp" #include "opto/c2compiler.hpp" Here _ comes before lower-case letters. From other places I see that _ comes after upper-case letters. I realize that this is caused by the ASCII value, but it is a bit unfortunate (IMHO). OTOH, maybe this will be consistent (the way I would like it, at least) if the sorting was done on lower-cased strings. src/hotspot/share/prims/foreignGlobals.cpp line 25: > 23: > 24: #include "classfile/javaClasses.hpp" > 25: #include "foreignGlobals.hpp" (For maintainers of this file, this should be prefixed with prims/) src/hotspot/share/services/diagnosticCommand.cpp line 72: > 70: #ifdef LINUX > 71: #include "mallocInfoDcmd.hpp" > 72: #include "os_posix.hpp" This should probably be: #ifdef LINUX #include "mallocInfoDcmd.hpp" #include "os_posix.hpp" #include "trimCHeapDCmd.hpp" #endif #ifdef LINUX #include #endif (and missing prefix should be added by maintainers) ------------- Changes requested by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24180#pullrequestreview-2714925291 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012784742 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012808108 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012812085 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012816294 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012818838 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012819309 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012822001 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012823415 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012826026 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012826486 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012829497 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012853306 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012856105 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012861794 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012862974 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012866552 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012867561 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012867729 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012867935 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012869598 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012868391 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012871019 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012872217 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012885535 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012877987 PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012889539 From erikj at openjdk.org Tue Mar 25 21:09:18 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 25 Mar 2025 21:09:18 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v4] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 20:16:51 GMT, Frederic Thevenet wrote: > > Using the log file from ExecuteWithLog as the recipe target to work around changing/signing the actual target file in place is an interesting choice, but I think it will work. Have you tried incremental builds thoroughly? > > Hmm... If think you're right to be suspicious about this; I just realized this approach has a pretty big flaw: in the event of a failure occurring in the script, `make` will delete the file used as the target, which in this case is bad since not only the job failed, but you've just lost the log file that could have helped you understand why! To be fair, what's in the `ExecuteWithLog` file should also be present in `build.log`, but it will mixed up with everything else and potentially a pain to piece back together. > > I'm leaning toward reverting to my initial idea, which was to add the command that calls the script as part of the linking recipe. I decided to extract it in its own to avoid duplication, since linking for Windows and macOS/Linux is split across two source files, but I'm thinking that might not be justified, since it's only a couple of lines. This also has the benefit of putting to rest any worries w.r.t. incremental builds, I think. In my experience there are two good ways to handle it. 1. Put it in the same recipe. 2. Create a separate rule and recipe, but then the output file needs to be different from the source file. 2 is generally better and what I usually go for, but it also gets more complicated. In this case we would want the final location to stay the same, so would need a different intermediate name or location for the linker output when signing is enabled. Changing the name of the file is likely to cause other downstream issues, so linking into a different (sub)directory is probably best in that case. The script would need to take two parameters, input file and output file. But I'm also good with keeping it simpler and going with 1, especially since this isn't going to be a common operation for daily building with incremental builds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2752549732 From dnsimon at openjdk.org Tue Mar 25 21:22:14 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 25 Mar 2025 21:22:14 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote: > This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. Thanks for all the comments so far. First thing is that my tool does nothing about re-ordering block of conditional includes vs unconditional includes. I briefly looked into that but it gets very complicated, very quickly. That kind of re-ordering will have to continue to be done manually or someone is going to have to invest significant time in enhancing/replacing the tool I wrote. Also, the tool tries to not change the number of lines in the original file. It should only add blank lines where necessary to separate user includes from sys includes. This explains some of the extra blank lines. For example, if the original was: 1: #include "a.h" 2: 3: #include "b.h" 4: 5: #include 6: 7: #include the output is: 1: #include "a.h" 2: #include "b.h" 3: 4: #include 5: #include 6: 7: Once again, I'd prefer to keep the tool simple and focused on the main task of ordering includes. Cleaning up extraneous blank lines can be done manually after running the tool. I'm currently working on converting `sort_includes.py` to `SortIncludes.java`. Once done, I'll open a second PR and limit changes to the C++ files I'm comfortable with changing and testing (namely in JVMCI directories). I will include a jtreg test to ensure these changes do not regress. Follow up issues can then be opened for working on the remaining C++ files. The main point of this initial PR is to show that such a tool can be useful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24180#issuecomment-2752572125 From dnsimon at openjdk.org Tue Mar 25 21:27:22 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 25 Mar 2025 21:27:22 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote: > This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. bin/sort_includes.py line 117: > 115: for filename in filenames: > 116: file = Path(dirpath).joinpath(filename) > 117: if file.suffix in (".cpp", "hpp"): `"hpp"` -> `".hpp"` This bug explains why there are no modified `*.hpp` files in the PR. And I've discovered that blindly sorting includes in these files (especially `*.inline.hpp` files) causes building to break quickly. This is another reason for the more incremental approach I suggest at https://github.com/openjdk/jdk/pull/24180#issuecomment-2752572125 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2012961564 From dnsimon at openjdk.org Tue Mar 25 22:22:23 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 25 Mar 2025 22:22:23 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 20:27:21 GMT, Stefan Karlsson wrote: >> This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). >> This script can also update files with unsorted includes. The second commit in this PR shows the result of running: >> >> python3 ./bin/sort_includes.py ./src/hotspot >> >> To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. >> >> Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. > > src/hotspot/share/opto/output.cpp line 39: > >> 37: #include "opto/block.hpp" >> 38: #include "opto/c2_MacroAssembler.hpp" >> 39: #include "opto/c2compiler.hpp" > > Hmm. > > #include "opto/c2_MacroAssembler.hpp" > #include "opto/c2compiler.hpp" > > Here _ comes before lower-case letters. From other places I see that _ comes after upper-case letters. I realize that this is caused by the ASCII value, but it is a bit unfortunate (IMHO). OTOH, maybe this will be consistent (the way I would like it, at least) if the sorting was done on lower-cased strings. I think it's simplest to follow ASCII sorting but don't have a strong opinion if others would prefer for strings to be lower-cased before sorting. The important thing is that the same order is used everywhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2013015247 From syan at openjdk.org Wed Mar 26 01:29:18 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 26 Mar 2025 01:29:18 GMT Subject: Integrated: 8352481: Enforce the use of lld with clang In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 06:57:04 GMT, SendaoYan wrote: > Hi all, > > There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR force use of lld when toolchain type is clang. Change has been verified locally. > > >> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out > Thu Mar 20 02:46:13 PM CST 2025 > GNU ld (GNU Binutils) 2.43.50.20240909 > File: a.out > Size: 792 Blocks: 8 IO Block: 4096 regular file > Device: 10303h/66307d Inode: 2355308 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) > Access: 2025-03-20 14:46:13.682967228 +0800 > Modify: 2025-03-20 14:46:13.682967228 +0800 > Change: 2025-03-20 14:46:13.682967228 +0800 > Birth: 2025-03-20 14:46:13.674966977 +0800 > -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out > a.out: data This pull request has now been integrated. Changeset: 0935ba9a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/0935ba9a8c808d372b387d0d0f479f854c121ec1 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod 8352481: Enforce the use of lld with clang Co-authored-by: Magnus Ihse Bursie Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.org/jdk/pull/24125 From syan at openjdk.org Wed Mar 26 01:29:18 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 26 Mar 2025 01:29:18 GMT Subject: RFR: 8352481: Enforce the use of lld with clang [v7] In-Reply-To: <5Pfopwfzh7s7QTLf9pALW4M6nBgum74T9iP1bzYIUMw=.eaed29cc-85f6-4259-8772-e240951d2a49@github.com> References: <5Pfopwfzh7s7QTLf9pALW4M6nBgum74T9iP1bzYIUMw=.eaed29cc-85f6-4259-8772-e240951d2a49@github.com> Message-ID: On Tue, 25 Mar 2025 15:57:12 GMT, Magnus Ihse Bursie wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Force use of lld when build os is not macosx > > Since I wrote like half the actual patch, I think it would be proper to get a review from someone more than me as well. Thanks @magicus @erikj79 for the suggestions and reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24125#issuecomment-2752988120 From juliosandi78 at yandex.com Wed Mar 26 04:59:47 2025 From: juliosandi78 at yandex.com (Julio Cesar Sanchez Diaz) Date: Tue, 25 Mar 2025 23:59:47 -0500 Subject: unsubscript Message-ID: <73981742965187@mail-sendbernar-production-main-50.klg.yp-c.yandex.net> unsubscript From stefank at openjdk.org Wed Mar 26 06:50:19 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 26 Mar 2025 06:50:19 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 21:24:41 GMT, Doug Simon wrote: >> This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). >> This script can also update files with unsorted includes. The second commit in this PR shows the result of running: >> >> python3 ./bin/sort_includes.py ./src/hotspot >> >> To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. >> >> Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. > > bin/sort_includes.py line 117: > >> 115: for filename in filenames: >> 116: file = Path(dirpath).joinpath(filename) >> 117: if file.suffix in (".cpp", "hpp"): > > `"hpp"` -> `".hpp"` > > This bug explains why there are no modified `*.hpp` files in the PR. And I've discovered that blindly sorting includes in these files (especially `*.inline.hpp` files) causes building to break quickly. This is another reason for the more incremental approach I suggest at https://github.com/openjdk/jdk/pull/24180#issuecomment-2752572125 I was going to ask that, but forgot about it once I had looked through all the files. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2013489315 From stefank at openjdk.org Wed Mar 26 07:03:18 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 26 Mar 2025 07:03:18 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 21:19:03 GMT, Doug Simon wrote: > Thanks for all the comments so far. > > First thing is that my tool does nothing about re-ordering block of conditional includes vs unconditional includes. I briefly looked into that but it gets very complicated, very quickly. That kind of re-ordering will have to continue to be done manually or someone is going to have to invest significant time in enhancing/replacing the tool I wrote. Yup. The extra effort needed to get the tool fully solve this is the reason why we haven't built a tool for this. There are a few scripts around but none is good enough to be promoted as *the* tool to correctly fix our includes. It is still going to be a great tool for the devs. > > Also, the tool tries to not change the number of lines in the original file. It should only add blank lines where necessary to separate user includes from sys includes. This explains some of the extra blank lines. For example, if the original was: > > ``` > 1: #include "a.h" > 2: > 3: #include "b.h" > 4: > 5: #include > 6: > 7: #include > ``` > > the output is: > > ``` > 1: #include "a.h" > 2: #include "b.h" > 3: > 4: #include > 5: #include > 6: > 7: > ``` > > Once again, I'd prefer to keep the tool simple and focused on the main task of ordering includes. Cleaning up extraneous blank lines can be done manually after running the tool. OK. We'll just have to make sure to clean these out after having the initial run of this tool. > > I'm currently working on converting `sort_includes.py` to `SortIncludes.java`. Once done, I'll open a second PR and limit changes to the C++ files I'm comfortable with changing and testing (namely in JVMCI directories). I will include a jtreg test to ensure these changes do not regress. > > Follow up issues can then be opened for working on the remaining C++ files. The main point of this initial PR is to show that such a tool can be useful. Sounds good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24180#issuecomment-2753413905 From stefank at openjdk.org Wed Mar 26 08:04:14 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 26 Mar 2025 08:04:14 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 22:19:39 GMT, Doug Simon wrote: >> src/hotspot/share/opto/output.cpp line 39: >> >>> 37: #include "opto/block.hpp" >>> 38: #include "opto/c2_MacroAssembler.hpp" >>> 39: #include "opto/c2compiler.hpp" >> >> Hmm. >> >> #include "opto/c2_MacroAssembler.hpp" >> #include "opto/c2compiler.hpp" >> >> Here _ comes before lower-case letters. From other places I see that _ comes after upper-case letters. I realize that this is caused by the ASCII value, but it is a bit unfortunate (IMHO). OTOH, maybe this will be consistent (the way I would like it, at least) if the sorting was done on lower-cased strings. > > I think it's simplest to follow ASCII sorting but don't have a strong opinion if others would prefer for strings to be lower-cased before sorting. The important thing is that the same order is used everywhere. I register my vote for using lower-casing the strings before sorting. Note that lower-casing before sorting retain the current prevailing sort-order of sorting `_` before the letters. This is also what you get if you use java's `String.CASE_INSENSITIVE_ORDER` (but not if you use `sort -f`, which upper-cases the strings). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24180#discussion_r2013575848 From jlahoda at openjdk.org Wed Mar 26 08:28:15 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 26 Mar 2025 08:28:15 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() Message-ID: The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. ------------- Commit messages: - Removing trailing whitespace - 8352693: Use a simpler console reader instead of JLine for System.console() Changes: https://git.openjdk.org/jdk/pull/24242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352693 Stats: 2502 lines in 22 files changed: 1872 ins; 600 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/24242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24242/head:pull/24242 PR: https://git.openjdk.org/jdk/pull/24242 From jsjolen at openjdk.org Wed Mar 26 08:48:13 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 26 Mar 2025 08:48:13 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote: > This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. No review from me (though happy to review the Java rewrite), but thank you for doing this :-). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24180#issuecomment-2753621032 From alanb at openjdk.org Wed Mar 26 09:03:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 26 Mar 2025 09:03:10 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. Can you coordinate with Naoto on this? There is a CSR in progress to switch Console back to using the java.base implementation by default. src/java.base/share/classes/module-info.java line 172: > 170: java.rmi, > 171: jdk.charsets, > 172: jdk.internal.le, What code in JLine is using shared secrets? I wonder what we need to change to avoid this. src/java.base/share/classes/module-info.java line 304: > 302: exports sun.nio.cs to > 303: jdk.charsets, > 304: jdk.internal.le; Same thing here. src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 51: > 49: } > 50: > 51: private static void doReadImpl(Reader reader, Writer out, boolean password, int firstLineOffset, IntSupplier terminalWidthSupplier, CleanableBuffer result) throws IOException { These overly long lines make it really hard to see the changes going forward so I think trim back some of these to make it easy to look at diffs in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24242#issuecomment-2753642709 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2013662676 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2013664086 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2013660028 From liangchenblue at gmail.com Wed Mar 26 09:03:57 2025 From: liangchenblue at gmail.com (Chen Liang) Date: Wed, 26 Mar 2025 04:03:57 -0500 Subject: unsubscript In-Reply-To: <73981742965187@mail-sendbernar-production-main-50.klg.yp-c.yandex.net> References: <73981742965187@mail-sendbernar-production-main-50.klg.yp-c.yandex.net> Message-ID: Hello, you can unsub by entering your email here: https://mail.openjdk.org/mailman/listinfo/build-dev On Tue, Mar 25, 2025, 11:59?PM Julio Cesar Sanchez Diaz < juliosandi78 at yandex.com> wrote: > unsubscript > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Wed Mar 26 09:26:22 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 26 Mar 2025 09:26:22 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port [v3] In-Reply-To: References: Message-ID: <38zw9WI_zW70F66Y44GWS6c5fXWHY0tBXmrnUqo7g3k=.e5d35577-fd80-44db-88bf-523e9f982ffc@github.com> On Tue, 25 Mar 2025 10:43:32 GMT, Aleksey Shipilev 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 pull request now contains five commits: > > - Merge branch 'master' into JDK-8345169-32bit-x86-be-gone > - 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 There we go! Thanks all! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2753715713 From shade at openjdk.org Wed Mar 26 09:26:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 26 Mar 2025 09:26:23 GMT Subject: Integrated: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev 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 pull request has now been integrated. Changeset: ee710fec Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/ee710fec21c4e886769576c17ad6db2ab91a84b4 Stats: 29733 lines in 25 files changed: 4 ins; 29728 del; 1 mod 8345169: Implement JEP 503: Remove the 32-bit x86 Port Reviewed-by: ihse, mdoerr, vlivanov, kvn, coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23906 From fthevenet at openjdk.org Wed Mar 26 09:28:49 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Wed, 26 Mar 2025 09:28:49 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v5] In-Reply-To: References: Message-ID: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Call the hook as part of the native linking recipe. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23807/files - new: https://git.openjdk.org/jdk/pull/23807/files/4c548a8b..6606a7e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23807&range=03-04 Stats: 28 lines in 3 files changed: 8 ins; 20 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23807/head:pull/23807 PR: https://git.openjdk.org/jdk/pull/23807 From fthevenet at openjdk.org Wed Mar 26 09:28:49 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Wed, 26 Mar 2025 09:28:49 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v4] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 21:06:41 GMT, Erik Joelsson wrote: >>> Using the log file from ExecuteWithLog as the recipe target to work around changing/signing the actual target file in place is an interesting choice, but I think it will work. Have you tried incremental builds thoroughly? >> >> Hmm... If think you're right to be suspicious about this; I just realized this approach has a pretty big flaw: in the event of a failure occurring in the script, `make` will delete the file used as the target, which in this case is bad since not only the job failed, but you've just lost the log file that could have helped you understand why! >> To be fair, what's in the `ExecuteWithLog` file should also be present in `build.log`, but it will mixed up with everything else and potentially a pain to piece back together. >> >> I'm leaning toward reverting to my initial idea, which was to add the command that calls the script as part of the linking recipe. I decided to extract it in its own to avoid duplication, since linking for Windows and macOS/Linux is split across two source files, but I'm thinking that might not be justified, since it's only a couple of lines. >> This also has the benefit of putting to rest any worries w.r.t. incremental builds, I think. > >> > Using the log file from ExecuteWithLog as the recipe target to work around changing/signing the actual target file in place is an interesting choice, but I think it will work. Have you tried incremental builds thoroughly? >> >> Hmm... If think you're right to be suspicious about this; I just realized this approach has a pretty big flaw: in the event of a failure occurring in the script, `make` will delete the file used as the target, which in this case is bad since not only the job failed, but you've just lost the log file that could have helped you understand why! To be fair, what's in the `ExecuteWithLog` file should also be present in `build.log`, but it will mixed up with everything else and potentially a pain to piece back together. >> >> I'm leaning toward reverting to my initial idea, which was to add the command that calls the script as part of the linking recipe. I decided to extract it in its own to avoid duplication, since linking for Windows and macOS/Linux is split across two source files, but I'm thinking that might not be justified, since it's only a couple of lines. This also has the benefit of putting to rest any worries w.r.t. incremental builds, I think. > > In my experience there are two good ways to handle it. > > 1. Put it in the same recipe. > 2. Create a separate rule and recipe, but then the output file needs to be different from the source file. > > 2 is generally better and what I usually go for, but it also gets more complicated. In this case we would want the final location to stay the same, so would need a different intermediate name or location for the linker output when signing is enabled. Changing the name of the file is likely to cause other downstream issues, so linking into a different (sub)directory is probably best in that case. The script would need to take two parameters, input file and output file. > > But I'm also good with keeping it simpler and going with 1, especially since this isn't going to be a common operation for daily building with incremental builds. Thanks @erikj79! I think I'd rather go with the simpler solution, as I indeed don't see a lot of practical benefit to the more sophisticated approach in this particular case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2753717992 From jlahoda at openjdk.org Wed Mar 26 10:28:12 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 26 Mar 2025 10:28:12 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 08:55:09 GMT, Alan Bateman wrote: > Can you coordinate with Naoto on this? There is a CSR in progress to switch Console back to using the java.base implementation by default. Right - but that still keeps the existing JLine-based provider, and so the problems it has still exist (albeit with a lower severity). This proposal is not the only sole possibility, of course. Other possibilities include removing the JLine-based provider, or fixing the problems in the JLine provider one-by-one. I don't object to any of these possibilities, although I didn't want to offer them in the first step. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24242#issuecomment-2753912618 From jlahoda at openjdk.org Wed Mar 26 10:32:13 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 26 Mar 2025 10:32:13 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: <-0ekDcnXdmkipjv7K2IvGae-vH4_IgjzlIqdt_qGf8g=.b7f70888-a9e1-45f8-a5f8-6b8bb1bfa124@github.com> On Wed, 26 Mar 2025 08:59:39 GMT, Alan Bateman wrote: >> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. >> >> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. >> >> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. > > src/java.base/share/classes/module-info.java line 172: > >> 170: java.rmi, >> 171: jdk.charsets, >> 172: jdk.internal.le, > > What code in JLine is using shared secrets? I wonder what we need to change to avoid this. Oops, sorry. I forgot to remove these (qualified export of `jdk.internal.access` and `sun.nio.cs`) after a refactoring. Will remove them in a next update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2013832440 From dnsimon at openjdk.org Wed Mar 26 10:43:25 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 26 Mar 2025 10:43:25 GMT Subject: Withdrawn: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote: > This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24180 From dnsimon at openjdk.org Wed Mar 26 10:43:25 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 26 Mar 2025 10:43:25 GMT Subject: RFR: 8352645: Add tool support to check order of includes In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote: > This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of include statements in C++ files are sorted alphabetically and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure include statements remain sorted. I've created #24247 to replace this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24180#issuecomment-2753968509 From ihse at openjdk.org Wed Mar 26 10:55:22 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 26 Mar 2025 10:55:22 GMT Subject: RFR: 8352692: Add support for extra jlink options [v2] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 18:30:30 GMT, Severin Gehwolf wrote: >> Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. >> >> Testing: >> - [x] GHA >> - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Use UTIL_ARG_WITH over AC_ARG_WITH LGTM ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24188#pullrequestreview-2716708804 From sgehwolf at openjdk.org Wed Mar 26 10:55:23 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 26 Mar 2025 10:55:23 GMT Subject: Integrated: 8352692: Add support for extra jlink options In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 10:37:10 GMT, Severin Gehwolf wrote: > Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. > > Testing: > - [x] GHA > - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. > > Thoughts? This pull request has now been integrated. Changeset: bc5cde1b Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/bc5cde1b198baf6e2e36d370b0aaa907c8f35777 Stats: 17 lines in 3 files changed: 17 ins; 0 del; 0 mod 8352692: Add support for extra jlink options Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.org/jdk/pull/24188 From sgehwolf at openjdk.org Wed Mar 26 10:55:23 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 26 Mar 2025 10:55:23 GMT Subject: RFR: 8352692: Add support for extra jlink options [v2] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 18:30:30 GMT, Severin Gehwolf wrote: >> Please review this simple change to allow for extra `jlink` flags to be passed to the JDK build by `configure`. The bug describes use-cases where this would be needed. >> >> Testing: >> - [x] GHA >> - [x] Manual tests with a fix for [JDK-8352689](https://bugs.openjdk.org/browse/JDK-8352689) together with a `jlink` arg file. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Use UTIL_ARG_WITH over AC_ARG_WITH Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24188#issuecomment-2753996102 From erikj at openjdk.org Wed Mar 26 12:44:23 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 26 Mar 2025 12:44:23 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v5] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 09:28:49 GMT, Frederic Thevenet wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Call the hook as part of the native linking recipe. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23807#pullrequestreview-2717022657 From ihse at openjdk.org Wed Mar 26 20:03:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 26 Mar 2025 20:03:11 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v5] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 09:28:49 GMT, Frederic Thevenet wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Call the hook as part of the native linking recipe. LGTM! ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23807#pullrequestreview-2718489388 From duke at openjdk.org Wed Mar 26 22:42:27 2025 From: duke at openjdk.org (Saint Wesonga) Date: Wed, 26 Mar 2025 22:42:27 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds Message-ID: The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. ------------- Commit messages: - Document how to build for Windows AArch64 Changes: https://git.openjdk.org/jdk/pull/24267/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24267&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353009 Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24267.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24267/head:pull/24267 PR: https://git.openjdk.org/jdk/pull/24267 From jwaters at openjdk.org Wed Mar 26 23:16:20 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 26 Mar 2025 23:16:20 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 10:42:50 GMT, Kim Barrett wrote: >>> Hi, the workaround 'disable lto in g1ParScanThreadState because of special inlining/flattening used there' is removed , why this works now ? >> >> The issue there was the `-Wattribute-warning` warnings that were being generated. But this change is suppressing >> those warnings in the LTO link: >> https://github.com/openjdk/jdk/blame/9d05cb8eff344fea3c6b9a9686b728ec53963978/make/hotspot/lib/JvmFeatures.gmk#L176C11-L176C11 >> Note that won't work with the new portable forbidding mechanism based on `deprecated` attributes. >> >> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. >> The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect. > >> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect. > > Turns out I didn't wait long enough. It does terminate after about 40 minutes, though not successfully. Instead the > build crashes with a failed assert: > > # Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620 > # assert(_thread->is_in_live_stack((address)this)) failed: not on stack? > > I've not tried to debug this. Maybe it's a consequence of one of those problems of bypassing an intentional implicit > noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that. > Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found > by normal compilation). I've been thinking this over, and I think the way forward to deal with G1 exploding HotSpot's size is to find a static analysis tool and use it to analyze g1ParScanThreadState.cpp, to find which methods it calls are from within its compilation unit, and which come from outside, from another compilation unit. Alternatively, if anyone knows which methods exactly should be flattened (Force inlined) and which ones should _not_ be, we could possibly fast track the process to making LTO viable on gcc higher than 13. My logic for prioritizing making LTO viable over fixing it for now is that there should be a motivating reason to fix LTO to work properly, and if LTO causes such massive bloat on any compiler, then it is no longer viable and the reason for fixing it is removed. Maybe @kimbarrett could provide some insight on which methods should be inlined and which should not be? If that's not possible, then hopefully someone has a static analysis tool suggestion for seeing the call graphs of g1ParScanThreadState.cpp ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2755970938 From syan at openjdk.org Thu Mar 27 02:25:22 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 27 Mar 2025 02:25:22 GMT Subject: RFR: 8352481: Enforce the use of lld with clang [v7] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 12:40:42 GMT, SendaoYan wrote: >> Hi all, >> >> There is an extra a.out file generated located in repository root directory after execute the configure command with llvm/clang compiler sometimes, not always. The a.out was generate by `$LINKER -Wl,-v 2>&1 | $HEAD -n 1`, shows as below. This PR force use of lld when toolchain type is clang. Change has been verified locally. >> >> >>> rm -rf a.out ; date ; ~/software/acc/x86_64/bin/clang -Wl,-v 2>&1 | head -n 1 ; stat a.out ; ls -lh a.out ; file a.out >> Thu Mar 20 02:46:13 PM CST 2025 >> GNU ld (GNU Binutils) 2.43.50.20240909 >> File: a.out >> Size: 792 Blocks: 8 IO Block: 4096 regular file >> Device: 10303h/66307d Inode: 2355308 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 995/yansendao) Gid: ( 992/yansendao) >> Access: 2025-03-20 14:46:13.682967228 +0800 >> Modify: 2025-03-20 14:46:13.682967228 +0800 >> Change: 2025-03-20 14:46:13.682967228 +0800 >> Birth: 2025-03-20 14:46:13.674966977 +0800 >> -rw-r----- 1 yansendao yansendao 792 Mar 20 14:46 a.out >> a.out: data > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Force use of lld when build os is not macosx make/autoconf/toolchain.m4 line 625: > 623: # Force use of lld, since that is what we expect when setting flags later on > 624: if test "x$TOOLCHAIN_TYPE" = xclang; then > 625: if test "x$OPENJDK_BUILD_OS" != "xmacosx"; then According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24125#discussion_r2015410411 From mbaesken at openjdk.org Thu Mar 27 09:12:11 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Mar 2025 09:12:11 GMT Subject: RFR: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote: > Hi all, > > Apologize for the inconvenience, fix of [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build broekn. > > According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. So this PR limite the use of lld on linux instead of non-macos. Hi, thanks for fixing the AIX build. I wonder what to do with BSD , afaik they also use clang and probably have the flag that is missing on AIX ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24270#issuecomment-2757270915 From fthevenet at openjdk.org Thu Mar 27 09:13:14 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Thu, 27 Mar 2025 09:13:14 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v5] In-Reply-To: References: Message-ID: <0_hV80shrF_X9v3YG-U8VZOAnpCloWzj_LSpcuNgReU=.f173bc7b-4812-43ec-b2dd-028eb2be0f05@github.com> On Wed, 26 Mar 2025 09:28:49 GMT, Frederic Thevenet wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Call the hook as part of the native linking recipe. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2757271575 From duke at openjdk.org Thu Mar 27 09:13:15 2025 From: duke at openjdk.org (duke) Date: Thu, 27 Mar 2025 09:13:15 GMT Subject: RFR: 8350801: Add a code signing hook to the JDK build system [v5] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 09:28:49 GMT, Frederic Thevenet wrote: >> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. >> >> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. >> >> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. >> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Call the hook as part of the native linking recipe. @fthevenet Your change (at version 6606a7e95baed31ea2fff2551fa2f4702c43a7e8) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2757273526 From mdoerr at openjdk.org Thu Mar 27 10:07:11 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 27 Mar 2025 10:07:11 GMT Subject: RFR: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote: > Hi all, > > Apologize for the inconvenience, fix of [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build broekn. > > According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. So this PR limite the use of lld on linux instead of non-macos. I think a positive list makes more sense. BSD can be added if needed. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24270#pullrequestreview-2720654898 From mbaesken at openjdk.org Thu Mar 27 10:15:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Mar 2025 10:15:07 GMT Subject: RFR: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote: > Hi all, > > Apologize for the inconvenience, fix of [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build broekn. > > According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. So this PR limite the use of lld on linux instead of non-macos. Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24270#pullrequestreview-2720673004 From duke at openjdk.org Thu Mar 27 10:15:07 2025 From: duke at openjdk.org (snake66) Date: Thu, 27 Mar 2025 10:15:07 GMT Subject: RFR: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 09:09:52 GMT, Matthias Baesken wrote: > I wonder what to do with BSD , afaik they also use clang and probably have the flag that is missing on AIX ? I'll have a look at it, but lld is the default linker, at least on FreeBSD, so I don't think we need the flag to begin with. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24270#issuecomment-2757486004 From fthevenet at openjdk.org Thu Mar 27 10:20:15 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Thu, 27 Mar 2025 10:20:15 GMT Subject: Integrated: 8350801: Add a code signing hook to the JDK build system In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 18:02:53 GMT, Frederic Thevenet wrote: > OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs. > > The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493. > > This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target. > This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms. This pull request has now been integrated. Changeset: 4100dc9d Author: Frederic Thevenet Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/4100dc9d4cdd5f0c202b2b2a32554e3aa4f15025 Stats: 45 lines in 6 files changed: 43 ins; 0 del; 2 mod 8350801: Add a code signing hook to the JDK build system Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.org/jdk/pull/23807 From duke at openjdk.org Thu Mar 27 11:39:07 2025 From: duke at openjdk.org (snake66) Date: Thu, 27 Mar 2025 11:39:07 GMT Subject: RFR: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote: > Hi all, > > Apologize for the inconvenience, fix of [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build broekn. > > According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. So this PR limite the use of lld on linux instead of non-macos. Builds fine on FreeBSD. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24270#issuecomment-2757726804 From mbaesken at openjdk.org Thu Mar 27 11:40:12 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Mar 2025 11:40:12 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote: > The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. Thanks for documenting it ! My colleague used instead '--build=aarch64-pc-cygwin' , is this equivalent ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2757729530 From mbaesken at openjdk.org Thu Mar 27 12:52:15 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Mar 2025 12:52:15 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters wrote: >> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated. >> >> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer >> - -flto is set to $(JOBS) instead of auto to better match what the user requested >> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-16 > - -fno-omit-frame-pointer in JvmFeatures.gmk > - Revert compilerWarnings_gcc.hpp > - General LTO fixes JvmFeatures.gmk > - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp > - Merge branch 'openjdk:master' into patch-16 > - Revert os.cpp > - Fix memory leak in jvmciEnv.cpp > - Stopgap fix in os.cpp > - Declaration fix in compilerWarnings_gcc.hpp > - ... and 2 more: https://git.openjdk.org/jdk/compare/06ed9958...9d05cb8e I did some builds today with gcc14.2.0 on Linux x86_64 . They looked good with and without LTO . Without lto / normal opt build du -sh images/jdk/lib/server/libjvm.so 27M images/jdk/lib/server/libjvm.so WITH lto du -sh images/jdk/lib/server/libjvm.so 24M images/jdk/lib/server/libjvm.so So even the code size reduction is visible. So gcc14 seems to work for me (but so far I only used it on Linux x86_64, can't tell about aarch64/ppc64le). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2757921798 From jwaters at openjdk.org Thu Mar 27 14:07:25 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 27 Mar 2025 14:07:25 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 12:49:10 GMT, Matthias Baesken wrote: > I did some builds today with gcc14.2.0 on Linux x86_64 . They looked good with and without LTO . Without lto / normal opt build du -sh images/jdk/lib/server/libjvm.so 27M images/jdk/lib/server/libjvm.so > > WITH lto du -sh images/jdk/lib/server/libjvm.so 24M images/jdk/lib/server/libjvm.so > > So even the code size reduction is visible. So gcc14 seems to work for me (but so far I only used it on Linux x86_64, can't tell about aarch64/ppc64le). Great, so it's yet another case of "Compiler works on one platform and royally ***** up on another" again. Sigh. I just love it when that happens. Thanks for the report on the gcc 14 Linux JVM sizes though, at least I can narrow it down with your help. I'll have to think of a way to fix this going forward ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2758178119 From jwaters at openjdk.org Thu Mar 27 14:20:28 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 27 Mar 2025 14:20:28 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters wrote: >> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated. >> >> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer >> - -flto is set to $(JOBS) instead of auto to better match what the user requested >> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-16 > - -fno-omit-frame-pointer in JvmFeatures.gmk > - Revert compilerWarnings_gcc.hpp > - General LTO fixes JvmFeatures.gmk > - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp > - Merge branch 'openjdk:master' into patch-16 > - Revert os.cpp > - Fix memory leak in jvmciEnv.cpp > - Stopgap fix in os.cpp > - Declaration fix in compilerWarnings_gcc.hpp > - ... and 2 more: https://git.openjdk.org/jdk/compare/62288a76...9d05cb8e Wait, sorry to trouble you further, but what does nm --demangle --reverse-sort --print-size --size-sort libjvm.so on HotSpot compiled by gcc 14 with LTO active yield as the largest symbol in the binary? (It should be the symbol listed at the very top) For me, I get the following as the largest symbols, because G1ParScanThreadState contains methods that are flattened to hell with LTO active: 0000000296f9b0c0 0000000000642d40 T G1ParScanThreadState::trim_queue_to_threshold(unsigned int) [clone .constprop.0] 0000000295125480 0000000000630080 T G1ParScanThreadState::trim_queue_to_threshold(unsigned int) 0000000296c68440 0000000000331c80 T G1ParScanThreadState::steal_and_trim_queue(GenericTaskQueueSet, (MemTag)5>*) [clone .constprop.0] 0000000295755500 0000000000331bc0 T G1ParScanThreadState::steal_and_trim_queue(GenericTaskQueueSet, (MemTag)5>*) 0000000295a87a80 000000000017cd00 T G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2758224080 PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2758228826 From mbaesken at openjdk.org Thu Mar 27 14:35:14 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Mar 2025 14:35:14 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 14:16:38 GMT, Julian Waters wrote: > Wait, sorry to trouble you further, but what does nm --demangle --reverse-sort --print-size --size-sort libjvm.so on HotSpot compiled by gcc 14 with LTO active yield as the largest symbol in the binary? (It should be the symbol listed at the very top) This is my output; maybe I have to add I used the 'normal' jdk head without patches, is that what I should do for a gcc14 build test? nm --demangle --reverse-sort --print-size --size-sort images/jdk/lib/server/libjvm.so | more 0000000000453ee0 000000000002320e t State::MachNodeGenerator(int) 0000000000970f70 0000000000018eb9 t CompilerToVM::initialize_intrinsics(JVMCIEnv*) 000000000140caa0 000000000000f018 b Matcher::mreg2regmask 0000000000993c80 000000000000a40d t JNIJVMCI::initialize_ids(JNIEnv_*) 0000000000ac16b0 0000000000009d16 t Matcher::Fixup_Save_On_Entry() 000000000143db00 0000000000008000 b _ZL9_elements.lto_priv.0 0000000001446d20 0000000000008000 b _free_list 000000000141e900 0000000000007d00 b DFSClosure::_reference_stack 00000000013d6d40 0000000000007668 d _ZL9flagTable.lto_priv.0 00000000013edf60 0000000000006c30 d VMStructs::localHotSpotVMStructs 00000000010463f0 0000000000006a06 t readConfiguration0(JNIEnv_*, JVMCIEnv*) [clone .isra.0] 0000000000d51dc0 00000000000067a2 t StubGenerator::generate_libmPow() 00000000010b12d0 0000000000006289 t G1ParScanThreadState::trim_queue_to_threshold(unsigned int) 0000000000e24550 00000000000061e8 t ClassVerifier::verify_method(methodHandle const&, JavaThread*) 0000000001076dd0 000000000000548d t State::DFA(int, Node const*) [clone .isra.0] 0000000000e1ba00 000000000000519d t VMError::report(outputStream*, bool) 00000000014521e0 0000000000005000 b TemplateInterpreter::_safept_table 000000000142cb60 0000000000005000 b TemplateInterpreter::_normal_table 0000000001431b60 0000000000005000 b TemplateInterpreter::_active_table 0000000000653790 0000000000004e12 t CompileBroker::print_heapinfo(outputStream*, char const*, unsigned long) 000000000075be40 0000000000004e0b t G1CollectedHeap::do_collection_pause_at_safepoint_helper() 0000000000b90260 0000000000004a41 t Parse::do_one_bytecode() [clone .part.0] 00000000010c1f20 00000000000049e6 t d_print_comp_inner 0000000000c1e180 0000000000004594 t ServiceThread::service_thread_entry(JavaThread*, JavaThread*) 00000000005ad7c0 0000000000004424 t C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) 0000000000d260b0 000000000000440a t PhaseStringOpts::replace_string_concat(StringConcat*) 0000000000e48920 00000000000042e5 t VM_Version::initialize() 0000000000afbad0 0000000000004240 t Method::init_intrinsic_id(vmSymbolID) 00000000010200d0 00000000000040ab t PSParallelCompact::invoke_no_policy(bool) [clone .isra.0] 000000000051f230 0000000000004054 t Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) 000000000065c060 0000000000004015 t Compile::Code_Gen() 0000000000663060 0000000000003fec t CompileBroker::compiler_thread_loop() 000000000070d9b0 0000000000003fd7 t ConnectionGraph::do_analysis(Compile*, PhaseIterGVN*) 0000000000be8890 0000000000003f8e t PhaseChaitin::Split(unsigned int, ResourceArea*) 0000000000818730 0000000000003f82 t PhaseChaitin::build_ifg_physical(ResourceArea*) 0000000000fb1920 0000000000003f44 t SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle const&, int, BasicType*, VMRegPair*, BasicType) [clone .constprop.0] 00000000007e2ab0 0000000000003f41 t PhaseCFG::global_code_motion() 00000000013e8580 0000000000003e10 d JVMCIVMStructs::localHotSpotVMStructs 0000000000db3b00 0000000000003dff t TemplateInterpreterGenerator::generate_all() 0000000000f436d0 0000000000003d92 t initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*) [clone .constprop.0] 0000000000d6b680 0000000000003d42 t StubGenerator::generate_libmTan() 00000000004ff560 0000000000003d28 t BCEscapeAnalyzer::iterate_blocks(Arena*) 0000000000a2bfb0 0000000000003cef t VM_RedefineClasses::load_new_class_versions() [clone .part.0] 000000000073fde0 0000000000003ca2 t G1CollectedHeap::do_full_collection(bool, bool) 0000000000e8e170 0000000000003bea t ZDriverMajor::run_thread() 000000000103ec00 0000000000003b81 t JvmtiEnv::RetransformClasses(int, _jclass* const*) [clone .isra.0] 0000000000d18c50 0000000000003b4d t StubGenerator::generate_md5_implCompress(StubGenStubId) 0000000000a97160 0000000000003b20 t PhaseIdealLoop::auto_vectorize(IdealLoopTree*, VSharedData&) [clone .part.0] 00000000013df000 0000000000003aa8 d ruleName 00000000005c7e90 0000000000003a9f t PhiNode::Ideal(PhaseGVN*, bool) 00000000006a1ef0 0000000000003a9f t State::_sub_Op_AddP(Node const*) 0000000000e86880 0000000000003a74 t ZGeneration::select_relocation_set(ZGenerationId, bool) --More-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2758282021 From duke at openjdk.org Thu Mar 27 14:39:45 2025 From: duke at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 27 Mar 2025 14:39:45 GMT Subject: RFR: 8353063: make/ide/vscode: Invalid Configuration Values Message-ID: The indexer setting templates used by the `vscode-project-*` `make` targets contain invalid configuration values. For example, `C_Cpp.formatting": "Disabled"`is invalid because VSCode (or rather the extension) expects the value to be non-capitalized. This PR fixes these invalid configuration options. I tested the changes by generating VSCode workspaces and checking whether VSCode complains about invalid values. ------------- Commit messages: - make/ide/vscode: Fix invalid configuration values Changes: https://git.openjdk.org/jdk/pull/24280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353063 Stats: 12 lines in 3 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24280/head:pull/24280 PR: https://git.openjdk.org/jdk/pull/24280 From erikj at openjdk.org Thu Mar 27 18:12:46 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 27 Mar 2025 18:12:46 GMT Subject: RFR: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: <4e6LsxHxs5epJStS4JdcC35N6l4LGr3R0dheLgzdOUw=.1c154fa9-dfb9-447f-930c-28593a0f17e4@github.com> On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote: > Hi all, > > Apologize for the inconvenience, fix of [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build broekn. > > According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. So this PR limite the use of lld on linux instead of non-macos. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24270#pullrequestreview-2722982138 From erikj at openjdk.org Thu Mar 27 18:15:33 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 27 Mar 2025 18:15:33 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote: > The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. I think this is fine for now, but ideally we should make configure understand that the build platform can be windows-aarch64 even if Cygwin is x86 running through emulation, so that it just works out of the box. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24267#pullrequestreview-2722993902 From erikj at openjdk.org Thu Mar 27 18:19:20 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 27 Mar 2025 18:19:20 GMT Subject: RFR: 8353063: make/ide/vscode: Invalid Configuration Values In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 14:33:30 GMT, Manuel H?ssig wrote: > The indexer setting templates used by the `vscode-project-*` `make` targets contain invalid configuration values. For example, `C_Cpp.formatting": "Disabled"`is invalid because VSCode (or rather the extension) expects the value to be non-capitalized. This PR fixes these invalid configuration options. > > I tested the changes by generating VSCode workspaces and checking whether VSCode complains about invalid values. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24280#pullrequestreview-2723016729 From duke at openjdk.org Thu Mar 27 18:35:20 2025 From: duke at openjdk.org (Saint Wesonga) Date: Thu, 27 Mar 2025 18:35:20 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 11:37:29 GMT, Matthias Baesken wrote: > Thanks for documenting it ! My colleague used instead '--build=aarch64-pc-cygwin' , is this equivalent ? I don't think `--build=aarch64-pc-cygwin` is equivalent to `--openjdk-target=aarch64-unknown-cygwin`. The build experts can clarify this but my understanding is that `--openjdk-target` automatically sets the --host and --target options for cross compilation, which I (mistakenly) thought was your scenario. The `--build` option you are using will give you a native build, which is your goal. I filed https://bugs.openjdk.org/browse/JDK-8353066 per your suggestion that it would be good to automatically select the native build instead of requiring a flag for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2759060937 From duke at openjdk.org Thu Mar 27 18:38:22 2025 From: duke at openjdk.org (duke) Date: Thu, 27 Mar 2025 18:38:22 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote: > The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. @swesonga Your change (at version c15306a8213b48e369c2b40648a4fd1af2fe2dea) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2759067860 From naoto at openjdk.org Thu Mar 27 19:41:19 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 27 Mar 2025 19:41:19 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com> On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. I am not very familiar with those escape sequences/modes in the native console, but looks good to me. Sharing the common part as the base looks reasonable. src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 69: > 67: case 4: break READ; //EOF/Ctrl-D > 68: case 127: > 69: //backspace: Is it `delete`? src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 198: > 196: > 197: if (it.hasNext()) { > 198: out.append("\n\r"); I understand this is a simple console, but do we want to CR/LF/CRLF based on the platform? ------------- PR Review: https://git.openjdk.org/jdk/pull/24242#pullrequestreview-2723057740 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2017409982 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2017488129 From erikj at openjdk.org Thu Mar 27 19:41:18 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 27 Mar 2025 19:41:18 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 18:32:20 GMT, Saint Wesonga wrote: > I don't think `--build=aarch64-pc-cygwin` is equivalent to `--openjdk-target=aarch64-unknown-cygwin`. The build experts can clarify this but my understanding is that `--openjdk-target` automatically sets the --host and --target options for cross compilation, which I (mistakenly) thought was your scenario. The `--build` option you are using will give you a native build, which is your goal. I filed https://bugs.openjdk.org/browse/JDK-8353066 per your suggestion that it would be good to automatically select the native build instead of requiring a flag for that. Wait, are you saying you can get a native build to work by setting `--build=aarch64-pc-cygwin`? If so, then that's a better instruction IMO. Building on a windows-aarch64 machine, using x86 cygwin, is what I assumed to be the problematic case. If that can be achieved without configuring an explicit cross compilation build, then that is very much preferred. At the very least the instructions should mention this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2759273486 From naoto at openjdk.org Thu Mar 27 20:51:31 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 27 Mar 2025 20:51:31 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com> References: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com> Message-ID: On Thu, 27 Mar 2025 19:29:29 GMT, Naoto Sato wrote: >> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. >> >> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. >> >> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. > > src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 198: > >> 196: >> 197: if (it.hasNext()) { >> 198: out.append("\n\r"); > > I understand this is a simple console, but do we want to CR/LF/CRLF based on the platform? `line.seprator` system property can be used here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2017581921 From jwaters at openjdk.org Fri Mar 28 05:13:16 2025 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 28 Mar 2025 05:13:16 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 14:32:35 GMT, Matthias Baesken wrote: > > Wait, sorry to trouble you further, but what does nm --demangle --reverse-sort --print-size --size-sort libjvm.so on HotSpot compiled by gcc 14 with LTO active yield as the largest symbol in the binary? (It should be the symbol listed at the very top) > > This is my output; maybe I have to add that I used the 'normal' jdk head without patches, is that what I should do for a gcc14 build test? > > ``` > nm --demangle --reverse-sort --print-size --size-sort images/jdk/lib/server/libjvm.so | more > 0000000000453ee0 000000000002320e t State::MachNodeGenerator(int) > 0000000000970f70 0000000000018eb9 t CompilerToVM::initialize_intrinsics(JVMCIEnv*) > 000000000140caa0 000000000000f018 b Matcher::mreg2regmask > 0000000000993c80 000000000000a40d t JNIJVMCI::initialize_ids(JNIEnv_*) > 0000000000ac16b0 0000000000009d16 t Matcher::Fixup_Save_On_Entry() > 000000000143db00 0000000000008000 b _ZL9_elements.lto_priv.0 > 0000000001446d20 0000000000008000 b _free_list > 000000000141e900 0000000000007d00 b DFSClosure::_reference_stack > 00000000013d6d40 0000000000007668 d _ZL9flagTable.lto_priv.0 > 00000000013edf60 0000000000006c30 d VMStructs::localHotSpotVMStructs > 00000000010463f0 0000000000006a06 t readConfiguration0(JNIEnv_*, JVMCIEnv*) [clone .isra.0] > 0000000000d51dc0 00000000000067a2 t StubGenerator::generate_libmPow() > 00000000010b12d0 0000000000006289 t G1ParScanThreadState::trim_queue_to_threshold(unsigned int) > 0000000000e24550 00000000000061e8 t ClassVerifier::verify_method(methodHandle const&, JavaThread*) > 0000000001076dd0 000000000000548d t State::DFA(int, Node const*) [clone .isra.0] > 0000000000e1ba00 000000000000519d t VMError::report(outputStream*, bool) > 00000000014521e0 0000000000005000 b TemplateInterpreter::_safept_table > 000000000142cb60 0000000000005000 b TemplateInterpreter::_normal_table > 0000000001431b60 0000000000005000 b TemplateInterpreter::_active_table > 0000000000653790 0000000000004e12 t CompileBroker::print_heapinfo(outputStream*, char const*, unsigned long) > 000000000075be40 0000000000004e0b t G1CollectedHeap::do_collection_pause_at_safepoint_helper() > 0000000000b90260 0000000000004a41 t Parse::do_one_bytecode() [clone .part.0] > 00000000010c1f20 00000000000049e6 t d_print_comp_inner > 0000000000c1e180 0000000000004594 t ServiceThread::service_thread_entry(JavaThread*, JavaThread*) > 00000000005ad7c0 0000000000004424 t C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) > 0000000000d260b0 000000000000440a t PhaseStringOpts::replace_string_concat(StringConcat*) > 0000000000e48920 00000000000042e5 t VM_Version::initialize() > 0000000000afbad0 0000000000004240 t Method::init_intrinsic_id(vmSymbolID) > 00000000010200d0 00000000000040ab t PSParallelCompact::invoke_no_policy(bool) [clone .isra.0] > 000000000051f230 0000000000004054 t Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) > 000000000065c060 0000000000004015 t Compile::Code_Gen() > 0000000000663060 0000000000003fec t CompileBroker::compiler_thread_loop() > 000000000070d9b0 0000000000003fd7 t ConnectionGraph::do_analysis(Compile*, PhaseIterGVN*) > 0000000000be8890 0000000000003f8e t PhaseChaitin::Split(unsigned int, ResourceArea*) > 0000000000818730 0000000000003f82 t PhaseChaitin::build_ifg_physical(ResourceArea*) > 0000000000fb1920 0000000000003f44 t SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle const&, int, BasicType*, VMRegPair*, BasicType) [clone .constprop.0] > 00000000007e2ab0 0000000000003f41 t PhaseCFG::global_code_motion() > 00000000013e8580 0000000000003e10 d JVMCIVMStructs::localHotSpotVMStructs > 0000000000db3b00 0000000000003dff t TemplateInterpreterGenerator::generate_all() > 0000000000f436d0 0000000000003d92 t initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*) [clone .constprop.0] > 0000000000d6b680 0000000000003d42 t StubGenerator::generate_libmTan() > 00000000004ff560 0000000000003d28 t BCEscapeAnalyzer::iterate_blocks(Arena*) > 0000000000a2bfb0 0000000000003cef t VM_RedefineClasses::load_new_class_versions() [clone .part.0] > 000000000073fde0 0000000000003ca2 t G1CollectedHeap::do_full_collection(bool, bool) > 0000000000e8e170 0000000000003bea t ZDriverMajor::run_thread() > 000000000103ec00 0000000000003b81 t JvmtiEnv::RetransformClasses(int, _jclass* const*) [clone .isra.0] > 0000000000d18c50 0000000000003b4d t StubGenerator::generate_md5_implCompress(StubGenStubId) > 0000000000a97160 0000000000003b20 t PhaseIdealLoop::auto_vectorize(IdealLoopTree*, VSharedData&) [clone .part.0] > 00000000013df000 0000000000003aa8 d ruleName > 00000000005c7e90 0000000000003a9f t PhiNode::Ideal(PhaseGVN*, bool) > 00000000006a1ef0 0000000000003a9f t State::_sub_Op_AddP(Node const*) > 0000000000e86880 0000000000003a74 t ZGeneration::select_relocation_set(ZGenerationId, bool) > --More-- > ``` Yes, that should be good enough, thank you for sharing it. I'm baffled by how tiny the methods are on Linux, in particular G1ParScanThreadState::trim_queue_to_threshold(unsigned int) only being 25KB is astonishing to me. I have no clue why flatten causes so much inlining on Windows to the point where it results in massive 5MB G1 methods, but then it's perfectly fine on Windows. I really wonder why the things I have to solve can never be easy sometimes ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2760210133 From syan at openjdk.org Fri Mar 28 06:06:25 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 28 Mar 2025 06:06:25 GMT Subject: RFR: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote: > Hi all, > > Apologize for the inconvenience, fix of [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build broekn. > > According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. So this PR limite the use of lld on linux instead of non-macos. Thanks all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24270#issuecomment-2760301704 From syan at openjdk.org Fri Mar 28 06:06:25 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 28 Mar 2025 06:06:25 GMT Subject: Integrated: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote: > Hi all, > > Apologize for the inconvenience, fix of [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build broekn. > > According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. So this PR limite the use of lld on linux instead of non-macos. This pull request has now been integrated. Changeset: 2ea1557a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/2ea1557a0fdaf551d75365d1351bfbd73319dcfb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8353005: AIX build broken after 8352481 Reviewed-by: mdoerr, mbaesken, erikj ------------- PR: https://git.openjdk.org/jdk/pull/24270 From thartmann at openjdk.org Fri Mar 28 09:01:27 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 28 Mar 2025 09:01:27 GMT Subject: RFR: 8353063: make/ide/vscode: Invalid Configuration Values In-Reply-To: References: Message-ID: <5wyvxK1Z-ifXroyHmzj8C1PiRyMzmBVzcMZuAZ4mnOQ=.b35dcd2d-d0fc-48a3-ab4a-387c942b5fd3@github.com> On Thu, 27 Mar 2025 14:33:30 GMT, Manuel H?ssig wrote: > The indexer setting templates used by the `vscode-project-*` `make` targets contain invalid configuration values. For example, `C_Cpp.formatting": "Disabled"`is invalid because VSCode (or rather the extension) expects the value to be non-capitalized. This PR fixes these invalid configuration options. > > I tested the changes by generating VSCode workspaces and checking whether VSCode complains about invalid values. Marked as reviewed by thartmann (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24280#pullrequestreview-2724722384 From duke at openjdk.org Fri Mar 28 09:01:27 2025 From: duke at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 28 Mar 2025 09:01:27 GMT Subject: Integrated: 8353063: make/ide/vscode: Invalid Configuration Values In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 14:33:30 GMT, Manuel H?ssig wrote: > The indexer setting templates used by the `vscode-project-*` `make` targets contain invalid configuration values. For example, `C_Cpp.formatting": "Disabled"`is invalid because VSCode (or rather the extension) expects the value to be non-capitalized. This PR fixes these invalid configuration options. > > I tested the changes by generating VSCode workspaces and checking whether VSCode complains about invalid values. This pull request has now been integrated. Changeset: 3e9a7a4a Author: Manuel H?ssig Committer: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/3e9a7a4aed168422473c941ff5626d0d65aaadfa Stats: 12 lines in 3 files changed: 0 ins; 0 del; 12 mod 8353063: make/ide/vscode: Invalid Configuration Values Reviewed-by: erikj, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/24280 From galder at redhat.com Fri Mar 28 09:25:44 2025 From: galder at redhat.com (Galder Zamarreno) Date: Fri, 28 Mar 2025 10:25:44 +0100 Subject: On passing --date to jrt-fs jar at build time Message-ID: Hi, I continue experimenting with building mainline on Nix and I've made some progress. Capstone, Ant and others are in, but I had to work around an issue when trying to run JMH benchmarks [1]. Seems like when `test` make target is run, `jrt-fs` jar file is created passing in `--date ...`. In Nix, I was getting this error: ``` /nix/store/5y040sypyg0amh0igxs9rnx5fmj0d88i-temurin-bin-23.0.2/bin/jar --create --date 1980-01-01T00:00:00Z --file /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/jrt-fs.jar --manifest /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/_the.jrt-fs.jar_manifest ... date 1980-01-01T00:00:00Z is not within the valid range 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z ``` @Andrew Leonard found the root of this validation in [2]. It seems unlikely this is going to change. The cause is that on Nix shell envs `$SOURCE_DATE_EPOCH` is set to 315532800 which is 1980-01-01T00:00:00Z. This can be easily worked around by unsetting SOURCE_DATE_EPOCH and that works fine for my use case. However, @Thomas Fitzsimmons had a very good point to make: > I also wonder why the test harness is passing --date $SOURCE_DATE_EPOCH, since the test jars are not distributed, not sure why they'd need to be reproducible... I think his question is valid. Why pass --date for a test jar? Thanks Galder [1] https://github.com/NixOS/nixpkgs/issues/387516#issuecomment-2760642591 [2] https://github.com/openjdk/jdk/pull/6481#issuecomment-982399628 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdoerr at openjdk.org Fri Mar 28 09:33:21 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 28 Mar 2025 09:33:21 GMT Subject: RFR: 8353005: AIX build broken after 8352481 In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 02:57:23 GMT, SendaoYan wrote: > Hi all, > > Apologize for the inconvenience, fix of [JDK-8352481](https://bugs.openjdk.org/browse/JDK-8352481) make AIX build broekn. > > According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker. So this PR limite the use of lld on linux instead of non-macos. Thanks for fixing it! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24270#issuecomment-2760703605 From alan.bateman at oracle.com Fri Mar 28 09:42:56 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 28 Mar 2025 09:42:56 +0000 Subject: On passing --date to jrt-fs jar at build time In-Reply-To: References: Message-ID: <8c6005a3-c196-4917-82ef-ef86e1b0abd6@oracle.com> On 28/03/2025 09:25, Galder Zamarreno wrote: > : > > However, @Thomas Fitzsimmons ?had a very > good point to make: > > > I also wonder why the test harness is passing |--date > $SOURCE_DATE_EPOCH|, since the test jars are not distributed, not sure > why they'd need to be reproducible... > > I think his question is valid. Why pass --date for a test jar? > I'm not sure what "test harness" and "test jar" means here but just to say that jrt-fs.jar is in the JDK run-time.? When an IDE running on JDK X needs to build/run a project for target JDK Y then it will use the jrt file system to access the classes in the target JDK. jrt-fs.jar is the provider implementation that JDK X will load to do this. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Fri Mar 28 10:00:30 2025 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 28 Mar 2025 11:00:30 +0100 Subject: On passing --date to jrt-fs jar at build time In-Reply-To: References: Message-ID: <36f0b94a1cea4623b40c2bd7e35d741e661fbd48.camel@redhat.com> On Fri, 2025-03-28 at 10:25 +0100, Galder Zamarreno wrote: > Hi, > > I continue experimenting with building mainline on Nix and I've made > some progress. Capstone, Ant and others are in, but I had to work > around an issue when trying to run JMH benchmarks [1]. > > Seems like when `test` make target is run, `jrt-fs` jar file is > created passing in `--date ...`. In Nix, I was getting this error: > > ``` > /nix/store/5y040sypyg0amh0igxs9rnx5fmj0d88i-temurin-bin-23.0.2/bin/jar --create --date 1980-01-01T00:00:00Z --file /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/jrt-fs.jar --manifest /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/_the.jrt-fs.jar_manifest > ... > date 1980-01-01T00:00:00Z is not within the valid range 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z > ``` > > @Andrew Leonard?found the root of this validation in [2]. It seems > unlikely this is going to change. > > The cause is that on Nix shell envs `$SOURCE_DATE_EPOCH` is set > to?315532800 which is?1980-01-01T00:00:00Z. This can be easily worked > around by unsetting?SOURCE_DATE_EPOCH and that works fine for my use > case. > > However,?@Thomas Fitzsimmons?had a very good point to make: > > > ?I also wonder why the test harness is passing --date > > $SOURCE_DATE_EPOCH, since the test jars are not distributed, not > > sure why they'd need to be reproducible... > > I think his question is valid. Why pass --date for a test jar? I might be missing something, but isn't the question about why pass --date $SOURCE_DATE_EPOCH ... when creating jrt-fs.jar? jrt-fs.jar isn't a test jar. It's the JDK 8 compatible FS provider for JDK 9+ to read the JRT files. Are you suggesting it's only happening when running "make test"? I'd assume the same would happen for 'make images' too after JDK-8288396. Couldn't you just set SOURCE_DATE_EPOCH to a value after 1980-01- 01T00:00:02Z (btw, that looks like a bug to me; valid range should really be T00:00:00Z). Thanks, Severin > [1]?https://github.com/NixOS/nixpkgs/issues/387516#issuecomment-2760642591 > [2]?https://github.com/openjdk/jdk/pull/6481#issuecomment-982399628 From galder at redhat.com Fri Mar 28 10:28:04 2025 From: galder at redhat.com (Galder Zamarreno) Date: Fri, 28 Mar 2025 11:28:04 +0100 Subject: On passing --date to jrt-fs jar at build time In-Reply-To: <36f0b94a1cea4623b40c2bd7e35d741e661fbd48.camel@redhat.com> References: <36f0b94a1cea4623b40c2bd7e35d741e661fbd48.camel@redhat.com> Message-ID: On Fri, Mar 28, 2025 at 11:00?AM Severin Gehwolf wrote: > On Fri, 2025-03-28 at 10:25 +0100, Galder Zamarreno wrote: > > Hi, > > > > I continue experimenting with building mainline on Nix and I've made > > some progress. Capstone, Ant and others are in, but I had to work > > around an issue when trying to run JMH benchmarks [1]. > > > > Seems like when `test` make target is run, `jrt-fs` jar file is > > created passing in `--date ...`. In Nix, I was getting this error: > > > > ``` > > /nix/store/5y040sypyg0amh0igxs9rnx5fmj0d88i-temurin-bin-23.0.2/bin/jar > --create --date 1980-01-01T00:00:00Z --file > /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/jrt-fs.jar > --manifest > /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/_the.jrt-fs.jar_manifest > > > ... > > date 1980-01-01T00:00:00Z is not within the valid range > 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z > > ``` > > > > @Andrew Leonard found the root of this validation in [2]. It seems > > unlikely this is going to change. > > > > The cause is that on Nix shell envs `$SOURCE_DATE_EPOCH` is set > > to 315532800 which is 1980-01-01T00:00:00Z. This can be easily worked > > around by unsetting SOURCE_DATE_EPOCH and that works fine for my use > > case. > > > > However, @Thomas Fitzsimmons had a very good point to make: > > > > > I also wonder why the test harness is passing --date > > > $SOURCE_DATE_EPOCH, since the test jars are not distributed, not > > > sure why they'd need to be reproducible... > > > > I think his question is valid. Why pass --date for a test jar? > > I might be missing something, but isn't the question about why pass > > --date $SOURCE_DATE_EPOCH > > ... when creating jrt-fs.jar? jrt-fs.jar isn't a test jar. It's the JDK > 8 compatible FS provider for JDK 9+ to read the JRT files. > > Are you suggesting it's only happening when running "make test"? I'd > assume the same would happen for 'make images' too after JDK-8288396. > Before trying to run `make test` I was just simply calling `make` and that didn't cause the jar to be created. Couldn't you just set SOURCE_DATE_EPOCH to a value after 1980-01- > 01T00:00:02Z (btw, that looks like a bug to me; valid range should > really be T00:00:00Z). > Yes that would also work, same as unsetting SOURCE_DATE_EPOCH. About the range, see the PR comment in [2] > > Thanks, > Severin > > > [1] > https://github.com/NixOS/nixpkgs/issues/387516#issuecomment-2760642591 > > [2] https://github.com/openjdk/jdk/pull/6481#issuecomment-982399628 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbaesken at openjdk.org Fri Mar 28 13:21:25 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Mar 2025 13:21:25 GMT Subject: RFR: 8349638: Build libjdwp with SIZE optimization In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote: > The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX. > On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there. > > On Linux x86_64 for example the lib shrinks from > 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M . > > On Linux ppc64le for example the lib shrinks from > 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M . The results for LOW/SIZE/HIGHEST for LIBJDWP are here (at least for our build envs at SAP) https://wiki.openjdk.org/display/Build/Native+library+optimization+level+research >From what I see, if we really care about speed in this lib we could also use HIGHEST optimization; there is not much code bloat with this. If we care about size of the lib/image size, SIZE brings us some improvements especially on Linux. I can also try HIGHEST + lto (this might bring us speed + smaller lib size at least with gcc). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2761344464 From mikael at openjdk.org Fri Mar 28 23:49:56 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 28 Mar 2025 23:49:56 GMT Subject: RFR: 8342984: Bump minimum boot jdk to JDK 24 Message-ID: With the JDK 24 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25. Testing: tier1-5, GHA ------------- Commit messages: - Update copyright year - 8342984: Bump minimum boot jdk to JDK 24 Changes: https://git.openjdk.org/jdk/pull/24305/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24305&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342984 Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/24305.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24305/head:pull/24305 PR: https://git.openjdk.org/jdk/pull/24305 From iris at openjdk.org Fri Mar 28 23:56:10 2025 From: iris at openjdk.org (Iris Clark) Date: Fri, 28 Mar 2025 23:56:10 GMT Subject: RFR: 8342984: Bump minimum boot jdk to JDK 24 In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 23:44:19 GMT, Mikael Vidstedt wrote: > With the JDK 24 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25. > > Testing: tier1-5, GHA Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24305#pullrequestreview-2727078104 From darcy at openjdk.org Sat Mar 29 00:47:05 2025 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 29 Mar 2025 00:47:05 GMT Subject: RFR: 8342984: Bump minimum boot jdk to JDK 24 In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 23:44:19 GMT, Mikael Vidstedt wrote: > With the JDK 24 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25. > > Testing: tier1-5, GHA Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24305#pullrequestreview-2727124695 From vlivanov at openjdk.org Sat Mar 29 01:18:33 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 29 Mar 2025 01:18:33 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 Message-ID: Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. Testing: hs-tier1 - hs-tier4, microbenchmarks ------------- Commit messages: - Build sleef on macos-aarch64 - Move libsleef sources to shared/native Changes: https://git.openjdk.org/jdk/pull/24306/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24306&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353217 Stats: 18 lines in 174 files changed: 14 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24306.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24306/head:pull/24306 PR: https://git.openjdk.org/jdk/pull/24306 From vlivanov at openjdk.org Sat Mar 29 01:18:33 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 29 Mar 2025 01:18:33 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: <4da5jkxaUrMVeNqLG1rD9wjSt96gC_Kp6-hNSfxJheE=.8a34d351-235f-43c6-a151-5e2eed622053@github.com> On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote: > Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. > > It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. > > PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks Microbenchmark results on Apple M1 Pro: Benchmark | Throughput | Allocation rate | | Before After | Before After | ======================|=======================================|===================================================| Float128Vector.ACOS | 3.856 ?0.013 1.941 ? 0.008 us/op | 6076.461 ? 20.067 0.007 ?0.001 MB/sec | Float128Vector.ASIN | 3.813 ?0.014 1.512 ? 0.017 us/op | 6145.040 ? 22.824 0.007 ?0.001 MB/sec | Float128Vector.ATAN | 7.124 ?0.040 2.220 ? 0.003 us/op | 3289.059 ? 18.539 0.007 ?0.001 MB/sec | Float128Vector.ATAN2 | 16.983 ?1.031 3.412 ? 0.038 us/op | 2075.808 ?127.179 0.007 ?0.001 MB/sec | Float128Vector.CBRT | 6.431 ?0.014 4.075 ? 0.011 us/op | 3643.789 ? 7.933 0.007 ?0.001 MB/sec | Float128Vector.COS | 8.269 ?0.094 5.614 ? 0.026 us/op | 2833.915 ? 32.041 0.007 ?0.001 MB/sec | Float128Vector.COSH | 5.779 ?0.020 3.072 ? 0.010 us/op | 4054.800 ? 14.028 0.007 ?0.001 MB/sec | Float128Vector.EXP | 5.456 ?0.006 0.936 ? 0.004 us/op | 4294.853 ? 5.025 0.007 ?0.001 MB/sec | Float128Vector.EXPM1 | 6.888 ?0.059 2.972 ? 0.010 us/op | 3402.363 ? 28.694 0.007 ?0.001 MB/sec | Float128Vector.HYPOT | 6.369 ?0.013 2.213 ? 0.008 us/op | 5519.051 ? 11.103 0.007 ?0.001 MB/sec | Float128Vector.LOG | 8.469 ?0.574 1.729 ? 0.004 us/op | 2775.039 ?157.629 0.007 ?0.001 MB/sec | Float128Vector.LOG10 | 15.235 ?1.039 1.830 ? 0.006 us/op | 1544.009 ?107.436 0.007 ?0.001 MB/sec | Float128Vector.LOG1P | 8.823 ?0.040 1.745 ? 0.014 us/op | 2655.757 ? 11.964 0.007 ?0.001 MB/sec | Float128Vector.POW | 27.511 ?0.918 7.467 ? 0.033 us/op | 1278.693 ? 42.538 0.007 ?0.001 MB/sec | Float128Vector.SIN | 7.846 ?0.063 5.822 ? 0.015 us/op | 2986.480 ? 24.025 0.007 ?0.001 MB/sec | Float128Vector.SINH | 5.747 ?0.033 3.206 ? 0.034 us/op | 4077.645 ? 23.305 0.007 ?0.001 MB/sec | Float128Vector.TAN | 22.337 ?0.533 6.114 ? 0.016 us/op | 1049.469 ? 24.969 0.007 ?0.001 MB/sec | Double128Vector.ACOS | 5.789 ?0.107 4.635 ? 0.013 us/op | 8097.069 ?146.593 0.007 ?0.001 MB/sec | Double128Vector.ASIN | 5.655 ?0.011 3.858 ? 0.017 us/op | 8287.521 ? 16.023 0.007 ?0.001 MB/sec | Double128Vector.ATAN | 10.082 ?0.046 6.016 ? 0.016 us/op | 4648.068 ? 21.401 0.007 ?0.001 MB/sec | Double128Vector.ATAN2 | 17.286 ?0.113 8.148 ? 0.015 us/op | 4067.019 ? 26.586 0.007 ?0.001 MB/sec | Double128Vector.CBRT | 9.779 ?0.048 8.861 ? 0.045 us/op | 4792.419 ? 23.381 0.007 ?0.001 MB/sec | Double128Vector.COS | 9.071 ?0.107 6.948 ? 0.027 us/op | 5166.999 ? 59.377 0.007 ?0.001 MB/sec | Double128Vector.COSH | 8.234 ?0.030 6.403 ? 0.025 us/op | 5692.144 ? 20.625 0.007 ?0.001 MB/sec | Double128Vector.EXP | 7.506 ?0.012 3.073 ? 0.013 us/op | 6243.783 ? 10.382 0.007 ?0.001 MB/sec | Double128Vector.EXPM1 | 9.122 ?0.036 6.122 ? 0.036 us/op | 5137.721 ? 20.350 0.007 ?0.001 MB/sec | Double128Vector.HYPOT | 13.445 ?0.248 4.596 ? 0.035 us/op | 5229.977 ? 96.222 0.007 ?0.001 MB/sec | Double128Vector.LOG | 10.396 ?0.042 4.629 ? 0.081 us/op | 4507.928 ? 18.101 0.007 ?0.001 MB/sec | Double128Vector.LOG10 | 13.923 ?0.046 4.889 ? 0.021 us/op | 3365.944 ? 11.078 0.007 ?0.001 MB/sec | Double128Vector.LOG1P | 12.336 ?0.045 5.010 ? 0.027 us/op | 3799.204 ? 13.816 0.007 ?0.001 MB/sec | Double128Vector.POW | 28.852 ?0.043 15.270 ? 0.081 us/op | 2436.503 ? 3.647 0.007 ?0.001 MB/sec | Double128Vector.SIN | 8.821 ?0.018 6.309 ? 0.037 us/op | 5313.077 ? 11.056 0.007 ?0.001 MB/sec | Double128Vector.SINH | 8.289 ?0.037 6.566 ? 0.029 us/op | 5654.264 ? 25.538 0.007 ?0.001 MB/sec | Double128Vector.TAN | 25.535 ?0.636 9.788 ? 0.036 us/op | 1836.177 ? 44.430 0.007 ?0.001 MB/sec | ------------- PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2762959907 From liach at openjdk.org Sat Mar 29 07:03:06 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 29 Mar 2025 07:03:06 GMT Subject: RFR: 8342984: Bump minimum boot jdk to JDK 24 In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 23:44:19 GMT, Mikael Vidstedt wrote: > With the JDK 24 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25. > > Testing: tier1-5, GHA Thanks for this bump. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24305#pullrequestreview-2727297093 From kvn at openjdk.org Sat Mar 29 17:46:10 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 29 Mar 2025 17:46:10 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: <9z8Yl3PRcBG47ggt1gTR_soWGo8lPUHt-A8yFOjgYjI=.9827b5a9-1ce3-4e24-b795-19814af3e30f@github.com> On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote: > Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. > > It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. > > PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24306#pullrequestreview-2727546251 From jwaters at openjdk.org Sat Mar 29 17:46:10 2025 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 29 Mar 2025 17:46:10 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote: > Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. > > It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. > > PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks make/modules/jdk.incubator.vector/Lib.gmk line 83: > 81: SRC := libsleef/lib, \ > 82: EXTRA_SRC := libsleef/generated, \ > 83: DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ DISABLED_WARNINGS_gcc is technically not needed, gcc is not a supported compiler on macOS, at least, not yet... If you feel that gcc support for macOS is a worthy addition to have to make the lives of future compiler porters, you can leave it in there. It's otherwise up to you whether you want to remove it or not (I personally like the idea of being able to compile for macOS with gcc in the future however) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24306#discussion_r2019888623 From jwaters at openjdk.org Sat Mar 29 17:49:06 2025 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 29 Mar 2025 17:49:06 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote: > Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. > > It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. > > PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks Is leaving the sources of sleef in share/native the right thing to do? That would implicitly mean to any developers that it's shared code for all currently supported operating systems: Windows, macOS, Linux and AIX, which may be rather confusing if it's only meant to be used on specific platforms. But I can also see why this was done, since duplication of sleef code for each platform would be pretty brutal, so there isn't an easy solution to this. I guess Windows/ARM64 could use it in the future, is that something that is intended? Perhaps that could be an excuse for leaving it under the share directory ------------- PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2763887362 From xtex at envs.net Sun Mar 30 06:58:30 2025 From: xtex at envs.net (Bingwu Zhang) Date: Sun, 30 Mar 2025 14:58:30 +0800 Subject: javac stack overflow on loongson3 with zero variant In-Reply-To: <9ba55b96-8832-48f6-be47-52b114347928@oracle.com> References: <4641863.LvFx2qVVIh@xtex1> <9ba55b96-8832-48f6-be47-52b114347928@oracle.com> Message-ID: <5272132.GXAFRqVoOG@xtex1> On Tuesday, March 25, 2025 11:52:29?PM China Standard Time Magnus Ihse Bursie wrote: > Is this reproducible? Did it started happening recently? If so, can you > bisect to which commit introduced the problem? Yes, it failed all loongson3 mips builds on the AOSC OS build service. As far as I can remember, it appeared during the JDK 24 development cycle. I have spent a whole weekend on bisecting, due to the poor performance of the loongson3 processors and some recent network issues of the AOSC's build servers (where I do the bisect). Current progress is ~16 commits/4 steps remaining. Now I am testing in 5e15415cb9c...a032de2904b. > Can you confirm that you are actually building natively on mips64? Yes. I am natively building on loongson3 (a variant of mips64). Cross-compiling from x86-64 is working. > If you try running without the javac server, does it change anything? > ("configure --disable-javac-server") No, the same error. > Is the default stack size different on mips64 than other platforms? > Maybe that default value should be changed if so. It is not. All architectures using the zero variant and LP64 use the same default stack size. (src/hotspot/os_cpu/linux_zero/globals_linux_zero.hpp) -- Bingwu Zhang / a.k.a. xtex @ Fri, 28 Mar 2025 10:12:21 +0000 From syan at openjdk.org Sun Mar 30 15:11:41 2025 From: syan at openjdk.org (SendaoYan) Date: Sun, 30 Mar 2025 15:11:41 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 Message-ID: Hi all, File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low. > cat java.c char a() { return 0; int b; if (a(&b)) return 0; } > gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address java.c: In function ?a?: java.c:6:1: error: control reaches end of non-void function [-Werror=return-type] 6 | } | ^ cc1: all warnings being treated as errors ------------- Commit messages: - 8304674: File java.c compile error with -fsanitize=address -O0 Changes: https://git.openjdk.org/jdk/pull/24318/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24318&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304674 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24318/head:pull/24318 PR: https://git.openjdk.org/jdk/pull/24318 From shade at openjdk.org Mon Mar 31 09:01:07 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 31 Mar 2025 09:01:07 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote: > Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. > > It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. > > PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks make/modules/jdk.incubator.vector/Lib.gmk line 85: > 83: DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ > 84: DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \ > 85: CFLAGS := $(NEON_CFLAGS), \ Is this supposed to match configs for linux-aarch64? I see we add `NEON_CFLAGS` here, and do _not_ add `vector_math_sve.c_CFLAGS` here. I would have thought those two are applicable to macos-aarch64 as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24306#discussion_r2020647457 From ihse at openjdk.org Mon Mar 31 10:17:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 10:17:19 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 19:38:28 GMT, Erik Joelsson wrote: > Wait, are you saying you can get a native build to work by setting --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO. No, it's not. If we could block the `--build` flag, we would. This is the built-in autoconf target/host/build system, that messes with the structure we use in OpenJDK (since we do not do canadian cross builds). So if you need to add configure option, this would be the correct one. However, we should be able to figure this out by ourselves. This can be solved by a patch in `config.sub` and/or `config.guess`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2765781468 From ihse at openjdk.org Mon Mar 31 10:18:33 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 10:18:33 GMT Subject: RFR: 8342984: Bump minimum boot jdk to JDK 24 In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 23:44:19 GMT, Mikael Vidstedt wrote: > With the JDK 24 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25. > > Testing: tier1-5, GHA Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24305#pullrequestreview-2728827582 From ihse at openjdk.org Mon Mar 31 12:10:14 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 12:10:14 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 17:41:29 GMT, Julian Waters wrote: >> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. >> >> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. >> >> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. >> >> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. >> >> Testing: hs-tier1 - hs-tier4, microbenchmarks > > make/modules/jdk.incubator.vector/Lib.gmk line 83: > >> 81: SRC := libsleef/lib, \ >> 82: EXTRA_SRC := libsleef/generated, \ >> 83: DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ > > DISABLED_WARNINGS_gcc is technically not needed, gcc is not a supported compiler on macOS, at least, not yet... > > If you feel that gcc support for macOS is a worthy addition to have to make the lives of future compiler porters, you can leave it in there. It's otherwise up to you whether you want to remove it or not (I personally like the idea of being able to compile for macOS with gcc in the future however) No, we should not have dead code "just in case". If someone were to support gcc on macos (seems implausible if that could ever be possible), then this is the least of their troubles. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24306#discussion_r2020917777 From ihse at openjdk.org Mon Mar 31 12:17:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 12:17:07 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote: > Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. > > It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. > > PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks The build code seems like it should be the same as for linux/aarch64. In fact, at this point, the code duplication should be removed into a single setup call. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2766037908 From ihse at openjdk.org Mon Mar 31 12:17:08 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 12:17:08 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 17:46:43 GMT, Julian Waters wrote: > Is leaving the sources of sleef in share/native the right thing to do? No, it should move to the least common directory for all platforms where it is needed. In this case, it should move to `unix` instead of `share`. But code that were to be used in e.g. windows and macos but not linux, should be put in `share`, even if it is not used on *all* platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2766044354 From ihse at openjdk.org Mon Mar 31 12:17:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 12:17:09 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 08:58:20 GMT, Aleksey Shipilev wrote: >> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. >> >> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. >> >> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. >> >> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. >> >> Testing: hs-tier1 - hs-tier4, microbenchmarks > > make/modules/jdk.incubator.vector/Lib.gmk line 85: > >> 83: DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ >> 84: DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \ >> 85: CFLAGS := $(NEON_CFLAGS), \ > > Is this supposed to match configs for linux-aarch64? I see we add `NEON_CFLAGS` here, and do _not_ add `vector_math_sve.c_CFLAGS` here. I would have thought those two are applicable to macos-aarch64 as well? This seems to be resurrected from some very old code. We don't have any `NEON_CFLAGS` anymore. This makes me wonder: @iwanowww what kind of testing have you done to ensure this works correctly? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24306#discussion_r2020922588 From ihse at openjdk.org Mon Mar 31 12:31:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 12:31:07 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote: > Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. > > It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. > > PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks Instead of trying to guide you how to fix this, I made the unification of all libsleef stanzas myself. It is available here: https://github.com/openjdk/jdk/commit/04feadda561b2f7a6afff440ab5b4e188361c048 That commit assumes that `vector_math_sve.c` should have `$(SVE_CFLAGS)` on mac as well as on linux. If that is not correct, then it needs to be adjusted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2766072866 From ihse at openjdk.org Mon Mar 31 12:35:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 12:35:11 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote: > The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. Wait a minute. I re-read the discussion a bit more carefully, and let my brain re-process what I said above... Is the goal here to document how you properly do cross-compilation for windows/aarch64 on windows/x64? If so, I think this is a correct solution, but the documentation should be more clear that this applies for cross-compiling to windows/aarch64 from x64 on cygwin. If the problem is that native builds on windows/aarch64 does not work, then it is a different issue that needs to be fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766081635 From ihse at openjdk.org Mon Mar 31 12:40:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 12:40:19 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. src/jdk.internal.le/windows/native/lible/WindowsTerminal.cpp line 32: > 30: #include > 31: #include > 32: //#include Should you really check in new files with commented-out code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020962013 From ihse at openjdk.org Mon Mar 31 12:51:37 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 12:51:37 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. make/modules/jdk.internal.le/Lib.gmk line 30: > 28: ################################################################################ > 29: > 30: ifeq ($(call isTargetOs, linux macosx windows), true) You might want to sync with the AIX guys to see if this should be enabled there as well. The unix version seems quite portable, so I assume it will work with very few adjustments, if any. @MBaesken Otherwise, what will happen if you try to run this on a platform without the corresponding native library? make/modules/jdk.internal.le/Lib.gmk line 35: > 33: NAME := le, \ > 34: TOOLCHAIN := TOOLCHAIN_LINK_CXX, \ > 35: OPTIMIZATION := LOW, \ We are trying to move away from using `LOW` as a default optimization level. If you believe this library is not performance critical, please use `SIZE` as the new default. Or, use `HIGHEST` if that gives performance benefits with no significant impact on library size. make/modules/jdk.internal.le/Lib.gmk line 36: > 34: TOOLCHAIN := TOOLCHAIN_LINK_CXX, \ > 35: OPTIMIZATION := LOW, \ > 36: JDK_LIBS := java.base:libjava, \ A quick glance through the native code revealed no obvious calls to libjava functions. Are you sure this dependency is needed? make/modules/jdk.internal.le/Lib.gmk line 37: > 35: OPTIMIZATION := LOW, \ > 36: JDK_LIBS := java.base:libjava, \ > 37: LIBS_unix := $(JDKLIB_LIBS) $(LIBCXX), \ LIBCXX is added automatically nowadays, so you can remove this entire line. make/modules/jdk.internal.le/Lib.gmk line 38: > 36: JDK_LIBS := java.base:libjava, \ > 37: LIBS_unix := $(JDKLIB_LIBS) $(LIBCXX), \ > 38: LIBS_windows := $(JDKLIB_LIBS) user32.lib, \ JDKLIB_LIBS is not used anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020982841 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020979597 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020976254 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020977176 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020976750 From qpzhang at openjdk.org Mon Mar 31 12:56:28 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Mon, 31 Mar 2025 12:56:28 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with three additional commits since the last revision: > > - Fixed a typo > > Signed-off-by: Patrick Zhang > - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS > > Signed-off-by: Patrick Zhang > - Revert the changes of adding new params to SetupNativeCompilation > > Signed-off-by: Patrick Zhang Hi @magicus , do you think my above clarifications regarding the unrelated code change and added comments acceptable, or do you still recommend removing those sections before merging? Thank you for confirming, and any advice on further changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2766136731 From syan at openjdk.org Mon Mar 31 13:03:18 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 31 Mar 2025 13:03:18 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 In-Reply-To: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com> References: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com> Message-ID: On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote: > in this particular case I wonder if not a pragma in the LEAVE macro would be better? I will try it later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2766150226 From ihse at openjdk.org Mon Mar 31 13:03:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 13:03:21 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with three additional commits since the last revision: > > - Fixed a typo > > Signed-off-by: Patrick Zhang > - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS > > Signed-off-by: Patrick Zhang > - Revert the changes of adding new params to SetupNativeCompilation > > Signed-off-by: Patrick Zhang I still have reservations. Let me re-read the patch to see if I can better understand what part of the code you find hard to understand, so I can be more constructive in my criticism. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2766149983 From ihse at openjdk.org Mon Mar 31 13:03:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 13:03:18 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 In-Reply-To: References: Message-ID: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com> On Sun, 30 Mar 2025 15:07:36 GMT, SendaoYan wrote: > Hi all, > File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low. > > >> cat java.c > char a() { > return 0; > int b; > if (a(&b)) > return 0; > } > >> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address > java.c: In function ?a?: > java.c:6:1: error: control reaches end of non-void function [-Werror=return-type] > 6 | } > | ^ > cc1: all warnings being treated as errors While I normally advocate using DISABLE_WARNING in makefiles instead of pragmas, in this particular case I wonder if not a pragma in the `LEAVE` macro would be better? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2766145747 From jwaters at openjdk.org Mon Mar 31 13:12:16 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 31 Mar 2025 13:12:16 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 05:10:33 GMT, Julian Waters wrote: > > Wait, sorry to trouble you further, but what does nm --demangle --reverse-sort --print-size --size-sort libjvm.so on HotSpot compiled by gcc 14 with LTO active yield as the largest symbol in the binary? (It should be the symbol listed at the very top) > > This is my output; maybe I have to add that I used the 'normal' jdk head without patches, is that what I should do for a gcc14 build test? > > ``` > nm --demangle --reverse-sort --print-size --size-sort images/jdk/lib/server/libjvm.so | more > 0000000000453ee0 000000000002320e t State::MachNodeGenerator(int) > 0000000000970f70 0000000000018eb9 t CompilerToVM::initialize_intrinsics(JVMCIEnv*) > 000000000140caa0 000000000000f018 b Matcher::mreg2regmask > 0000000000993c80 000000000000a40d t JNIJVMCI::initialize_ids(JNIEnv_*) > 0000000000ac16b0 0000000000009d16 t Matcher::Fixup_Save_On_Entry() > 000000000143db00 0000000000008000 b _ZL9_elements.lto_priv.0 > 0000000001446d20 0000000000008000 b _free_list > 000000000141e900 0000000000007d00 b DFSClosure::_reference_stack > 00000000013d6d40 0000000000007668 d _ZL9flagTable.lto_priv.0 > 00000000013edf60 0000000000006c30 d VMStructs::localHotSpotVMStructs > 00000000010463f0 0000000000006a06 t readConfiguration0(JNIEnv_*, JVMCIEnv*) [clone .isra.0] > 0000000000d51dc0 00000000000067a2 t StubGenerator::generate_libmPow() > 00000000010b12d0 0000000000006289 t G1ParScanThreadState::trim_queue_to_threshold(unsigned int) > 0000000000e24550 00000000000061e8 t ClassVerifier::verify_method(methodHandle const&, JavaThread*) > 0000000001076dd0 000000000000548d t State::DFA(int, Node const*) [clone .isra.0] > 0000000000e1ba00 000000000000519d t VMError::report(outputStream*, bool) > 00000000014521e0 0000000000005000 b TemplateInterpreter::_safept_table > 000000000142cb60 0000000000005000 b TemplateInterpreter::_normal_table > 0000000001431b60 0000000000005000 b TemplateInterpreter::_active_table > 0000000000653790 0000000000004e12 t CompileBroker::print_heapinfo(outputStream*, char const*, unsigned long) > 000000000075be40 0000000000004e0b t G1CollectedHeap::do_collection_pause_at_safepoint_helper() > 0000000000b90260 0000000000004a41 t Parse::do_one_bytecode() [clone .part.0] > 00000000010c1f20 00000000000049e6 t d_print_comp_inner > 0000000000c1e180 0000000000004594 t ServiceThread::service_thread_entry(JavaThread*, JavaThread*) > 00000000005ad7c0 0000000000004424 t C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) > 0000000000d260b0 000000000000440a t PhaseStringOpts::replace_string_concat(StringConcat*) > 0000000000e48920 00000000000042e5 t VM_Version::initialize() > 0000000000afbad0 0000000000004240 t Method::init_intrinsic_id(vmSymbolID) > 00000000010200d0 00000000000040ab t PSParallelCompact::invoke_no_policy(bool) [clone .isra.0] > 000000000051f230 0000000000004054 t Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) > 000000000065c060 0000000000004015 t Compile::Code_Gen() > 0000000000663060 0000000000003fec t CompileBroker::compiler_thread_loop() > 000000000070d9b0 0000000000003fd7 t ConnectionGraph::do_analysis(Compile*, PhaseIterGVN*) > 0000000000be8890 0000000000003f8e t PhaseChaitin::Split(unsigned int, ResourceArea*) > 0000000000818730 0000000000003f82 t PhaseChaitin::build_ifg_physical(ResourceArea*) > 0000000000fb1920 0000000000003f44 t SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle const&, int, BasicType*, VMRegPair*, BasicType) [clone .constprop.0] > 00000000007e2ab0 0000000000003f41 t PhaseCFG::global_code_motion() > 00000000013e8580 0000000000003e10 d JVMCIVMStructs::localHotSpotVMStructs > 0000000000db3b00 0000000000003dff t TemplateInterpreterGenerator::generate_all() > 0000000000f436d0 0000000000003d92 t initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*) [clone .constprop.0] > 0000000000d6b680 0000000000003d42 t StubGenerator::generate_libmTan() > 00000000004ff560 0000000000003d28 t BCEscapeAnalyzer::iterate_blocks(Arena*) > 0000000000a2bfb0 0000000000003cef t VM_RedefineClasses::load_new_class_versions() [clone .part.0] > 000000000073fde0 0000000000003ca2 t G1CollectedHeap::do_full_collection(bool, bool) > 0000000000e8e170 0000000000003bea t ZDriverMajor::run_thread() > 000000000103ec00 0000000000003b81 t JvmtiEnv::RetransformClasses(int, _jclass* const*) [clone .isra.0] > 0000000000d18c50 0000000000003b4d t StubGenerator::generate_md5_implCompress(StubGenStubId) > 0000000000a97160 0000000000003b20 t PhaseIdealLoop::auto_vectorize(IdealLoopTree*, VSharedData&) [clone .part.0] > 00000000013df000 0000000000003aa8 d ruleName > 00000000005c7e90 0000000000003a9f t PhiNode::Ideal(PhaseGVN*, bool) > 00000000006a1ef0 0000000000003a9f t State::_sub_Op_AddP(Node const*) > 0000000000e86880 0000000000003a74 t ZGeneration::select_relocation_set(ZGenerationId, bool) > --More-- > ``` I've spoken to the gcc maintainers, according to them problems with -fuse-linker-plugin can be a potential cause of the fiasco with the inlining here. Sorry to trouble you further, but what happens if you replace both instances of -fuse-linker-plugin with -fno-use-linker-plugin on Linux in JvmFeatures.gmk? Does any change occur in the nm output or is the resulting JVM massively bloated? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2766182048 From erikj at openjdk.org Mon Mar 31 13:19:25 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 31 Mar 2025 13:19:25 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 12:31:10 GMT, Magnus Ihse Bursie wrote: > Wait a minute. I re-read the discussion a bit more carefully, and let my brain re-process what I said above... > > Is the goal here to document how you properly do cross-compilation for windows/aarch64 on windows/x64? If so, I think this is a correct solution, but the documentation should be more clear that this applies for cross-compiling to windows/aarch64 from x64 on cygwin. > > If the problem is that native builds on windows/aarch64 does not work, then it is a different issue that needs to be fixed. The problem applies to both native and cross compilation, though cross compilation is no different than other platforms. The reason native compilation doesn't work on Cygwin is that there is no aarch64 distro of Cygwin, so even a native windows aarch64 build will use an x64 version of Cygwin running in emulated mode (I don't know the name on Windows, but pretty much the same as rosetta on mac). This trips up configure into thinking we are running on a native windows x64 machine, and it's the reason why telling configure that the **build** platform is `aarch64-pc-cygwin` helps. Caveat, this is all based on what I've heard, I've never had access to a windows-aarch64 machine. I completely agree that fixing this detection issue is better than documenting, but I also think that documenting how to perform a native build is better than how to perform a cross build on a native machine. Cross compiling works, but adds increased complexity and build time unnecessarily in this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766199206 From ihse at openjdk.org Mon Mar 31 13:27:42 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 13:27:42 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Tue, 25 Mar 2025 01:54:33 GMT, Patrick Zhang wrote: >> make/common/native/Flags.gmk line 125: >> >>> 123: endif >>> 124: ifeq ($(STATIC_LIBS), true) >>> 125: $1_EXTRA_CXXFLAGS += -DSTATIC_BUILD=1 >> >> This seems unrelated to the fix? > >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. > > Unrelated, after the fix got limited to `JvmFlags.gmk` only. > However, it is a practical bug, and existing tests did not cover the corner case. As described in the No.3 bullet of this PR. The problem showed up when I tested applying `EXTRA_CXXFLAGS to `precompiled.hpp.gch`. It is a simple and tiny fix which may not require a separate PR I thought, does it? > > FYI, the failures on linux-x64-static and linux-x64-static-libs tests, captured by OpenJDK GHA Sanity Checks: https://github.com/cnqpzhang/jdk/actions/runs/13943096440. You are correct that this is a bug, but the fix should not be sneaked in under the guise of another problem. I created https://bugs.openjdk.org/browse/JDK-8353272 for this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24115#discussion_r2021042829 From ihse at openjdk.org Mon Mar 31 13:31:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 13:31:54 GMT Subject: RFR: 8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683 Message-ID: <5UuTTHeKv6t_TKqoEORD5lWto_glgrsDZDJKsY0EK5M=.70e0fc2a-b364-4e77-89b4-6a5fc5d78e9e@github.com> It turns out one instance of STATIC_LIB_CFLAGS was missed in Flags.gmk when fixing [JDK-8345683](https://bugs.openjdk.org/browse/JDK-8345683). This was noticed by @cnqpzhang in https://github.com/openjdk/jdk/pull/24115/files#r2011164138. ------------- Commit messages: - 8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683 Changes: https://git.openjdk.org/jdk/pull/24327/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24327&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353272 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24327.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24327/head:pull/24327 PR: https://git.openjdk.org/jdk/pull/24327 From ihse at openjdk.org Mon Mar 31 13:38:40 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 13:38:40 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: <2Rl4gnFu2cz_UPdNvan3hjemdnmjKs-ZOSxtyKasLcw=.35697db2-119c-479e-ab44-8d1c3f24b095@github.com> On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with three additional commits since the last revision: > > - Fixed a typo > > Signed-off-by: Patrick Zhang > - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS > > Signed-off-by: Patrick Zhang > - Revert the changes of adding new params to SetupNativeCompilation > > Signed-off-by: Patrick Zhang I've now re-read it all, and I stand behind my position that the comment should be removed. I agree that the CFLAGS handling in the build system is obscure, and surprising. There is an old JBS issue from 2012 (!) tracking this: https://bugs.openjdk.org/browse/JDK-8001877 (see also https://bugs.openjdk.org/browse/JDK-8333089). It's a shame that this has not been fixed, but the problem is that the current situation is so complicated that it will take quite an effort to disentangle the mess, which combined with the limited ways to raise abstraction available in make makes this a much larger undertaking than maybe is apparent at first glance. So in this context, having the proposed comment at that place only just adds to the confusion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2766258358 From ihse at openjdk.org Mon Mar 31 13:44:31 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 31 Mar 2025 13:44:31 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote: > The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. But is the problem that we just fails to detect the *build* platform, and thus generates build tools for x64, instead of aarch64, which makes the build fail? (Also, why doesn't the rosetta-equivalent kick in in that case?) Or do we also fail to set the proper target platform, so that building on windows/aarch64 will in effect be a cross compilation to x64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766274494 From erikj at openjdk.org Mon Mar 31 14:11:20 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 31 Mar 2025 14:11:20 GMT Subject: RFR: 8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683 In-Reply-To: <5UuTTHeKv6t_TKqoEORD5lWto_glgrsDZDJKsY0EK5M=.70e0fc2a-b364-4e77-89b4-6a5fc5d78e9e@github.com> References: <5UuTTHeKv6t_TKqoEORD5lWto_glgrsDZDJKsY0EK5M=.70e0fc2a-b364-4e77-89b4-6a5fc5d78e9e@github.com> Message-ID: On Mon, 31 Mar 2025 13:27:32 GMT, Magnus Ihse Bursie wrote: > It turns out one instance of STATIC_LIB_CFLAGS was missed in Flags.gmk when fixing [JDK-8345683](https://bugs.openjdk.org/browse/JDK-8345683). This was noticed by @cnqpzhang in https://github.com/openjdk/jdk/pull/24115/files#r2011164138. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24327#pullrequestreview-2729432439 From qpzhang at openjdk.org Mon Mar 31 14:25:52 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Mon, 31 Mar 2025 14:25:52 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v3] In-Reply-To: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: > Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. > > The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. > > This PR does: > 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. > 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. > 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. > > Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: Remove the comments wrt not appending EXTRA_CFLAGS to JVM_CFLAGS Signed-off-by: Patrick Zhang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24115/files - new: https://git.openjdk.org/jdk/pull/24115/files/aa242dd5..5440ddc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24115/head:pull/24115 PR: https://git.openjdk.org/jdk/pull/24115 From erikj at openjdk.org Mon Mar 31 14:31:16 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 31 Mar 2025 14:31:16 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote: > The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. > But is the problem that we just fails to detect the _build_ platform, and thus generates build tools for x64, instead of aarch64, which makes the build fail? (Also, why doesn't the rosetta-equivalent kick in in that case?) > > Or do we also fail to set the proper target platform, so that building on windows/aarch64 will in effect be a cross compilation to x64? If configure thinks it's running on a build platform of windows-x64, why would it try to compile for any other target than windows-x64 by default? I don't think the build fails, it just builds for the wrong platform, but as I said, I never tried this myself, this is second hand information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766418606 From qpzhang at openjdk.org Mon Mar 31 14:31:56 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Mon, 31 Mar 2025 14:31:56 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v4] In-Reply-To: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: > Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. > > The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. > > This PR does: > 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. > 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. > 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. > > Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: Revertd the STATIC_LIB_CFLAGS fix as it is coverted by JDK-8353272 Signed-off-by: Patrick Zhang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24115/files - new: https://git.openjdk.org/jdk/pull/24115/files/5440ddc5..46c43921 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24115/head:pull/24115 PR: https://git.openjdk.org/jdk/pull/24115 From jlahoda at openjdk.org Mon Mar 31 14:36:16 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 31 Mar 2025 14:36:16 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 12:43:26 GMT, Magnus Ihse Bursie wrote: >> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. >> >> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. >> >> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. > > make/modules/jdk.internal.le/Lib.gmk line 36: > >> 34: TOOLCHAIN := TOOLCHAIN_LINK_CXX, \ >> 35: OPTIMIZATION := LOW, \ >> 36: JDK_LIBS := java.base:libjava, \ > > A quick glance through the native code revealed no obvious calls to libjava functions. Are you sure this dependency is needed? `CHECK_NULL` is used by the native code, originating in `jni_util.h`. But, looking at other libraries, seems that EXTRA_HEADER_DIRS := java.base:libjava, should be enough (i.e. replacing `JDK_LIBS` with `EXTRA_HEADER_DIRS`). Is there some even better way? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021174881 From qpzhang at openjdk.org Mon Mar 31 14:40:31 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Mon, 31 Mar 2025 14:40:31 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: <2Rl4gnFu2cz_UPdNvan3hjemdnmjKs-ZOSxtyKasLcw=.35697db2-119c-479e-ab44-8d1c3f24b095@github.com> References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> <2Rl4gnFu2cz_UPdNvan3hjemdnmjKs-ZOSxtyKasLcw=.35697db2-119c-479e-ab44-8d1c3f24b095@github.com> Message-ID: On Mon, 31 Mar 2025 13:35:24 GMT, Magnus Ihse Bursie wrote: > So in this context, having the proposed comment at that place only just adds to the confusion. Sure, I removed the comments with a new commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2766441330 From qpzhang at openjdk.org Mon Mar 31 14:40:33 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Mon, 31 Mar 2025 14:40:33 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Mon, 31 Mar 2025 13:24:25 GMT, Magnus Ihse Bursie wrote: >>> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. >> >> Unrelated, after the fix got limited to `JvmFlags.gmk` only. >> However, it is a practical bug, and existing tests did not cover the corner case. As described in the No.3 bullet of this PR. The problem showed up when I tested applying `EXTRA_CXXFLAGS to `precompiled.hpp.gch`. It is a simple and tiny fix which may not require a separate PR I thought, does it? >> >> FYI, the failures on linux-x64-static and linux-x64-static-libs tests, captured by OpenJDK GHA Sanity Checks: https://github.com/cnqpzhang/jdk/actions/runs/13943096440. > > You are correct that this is a bug, but the fix should not be sneaked in under the guise of another problem. > > I created https://bugs.openjdk.org/browse/JDK-8353272 for this. Reverted the fix. Thanks for helping file a new JBS and follow-ups. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24115#discussion_r2021172025 From duke at openjdk.org Mon Mar 31 14:43:14 2025 From: duke at openjdk.org (Saint Wesonga) Date: Mon, 31 Mar 2025 14:43:14 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 14:27:19 GMT, Erik Joelsson wrote: > > But is the problem that we just fails to detect the _build_ platform, and thus generates build tools for x64, instead of aarch64, which makes the build fail? (Also, why doesn't the rosetta-equivalent kick in in that case?) > > Or do we also fail to set the proper target platform, so that building on windows/aarch64 will in effect be a cross compilation to x64? > > If configure thinks it's running on a build platform of windows-x64, why would it try to compile for any other target than windows-x64 by default? I don't think the build fails, it just builds for the wrong platform, but as I said, I never tried this myself, this is second hand information. Correct, the build does not fail. It just builds for windows-x64, which one would not expect on a Windows AArch64 machine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766454002 From duke at openjdk.org Mon Mar 31 14:47:25 2025 From: duke at openjdk.org (Saint Wesonga) Date: Mon, 31 Mar 2025 14:47:25 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: <_v5s02jab1bagTjbypZDPTWbmnihi8Jsu-TBu7nxUFY=.69cd51f9-2d0b-4d2a-a775-cc5454b61dbd@github.com> On Mon, 31 Mar 2025 13:16:34 GMT, Erik Joelsson wrote: > > Wait a minute. I re-read the discussion a bit more carefully, and let my brain re-process what I said above... > > Is the goal here to document how you properly do cross-compilation for windows/aarch64 on windows/x64? If so, I think this is a correct solution, but the documentation should be more clear that this applies for cross-compiling to windows/aarch64 from x64 on cygwin. > > If the problem is that native builds on windows/aarch64 does not work, then it is a different issue that needs to be fixed. > > The problem applies to both native and cross compilation, though cross compilation is no different than other platforms. The reason native compilation doesn't work on Cygwin is that there is no aarch64 distro of Cygwin, so even a native windows aarch64 build will use an x64 version of Cygwin running in emulated mode (I don't know the name on Windows, but pretty much the same as rosetta on mac). This trips up configure into thinking we are running on a native windows x64 machine, and it's the reason why telling configure that the **build** platform is `aarch64-pc-cygwin` helps. Caveat, this is all based on what I've heard, I've never had access to a windows-aarch64 machine. > > I completely agree that fixing this detection issue is better than documenting, but I also think that documenting how to perform a native build is better than how to perform a cross build on a native machine. Cross compiling works, but adds increased complexity and build time unnecessarily in this case. Upon closer inspection, the --build option results in a native build (per the build system) but the ARM64 C++ compiler binary (cl.exe) is actually an x64 binary, so the compiler is running in emulated mode despite the build system thinking that a native build is happening. I'm investigating this in https://bugs.openjdk.org/browse/JDK-8353066 I propose changing the scope of this PR to documenting cross compilation for windows/aarch64 on windows/x64 and fixing the native build in https://bugs.openjdk.org/browse/JDK-8353066 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766469401 From duke at openjdk.org Mon Mar 31 15:04:14 2025 From: duke at openjdk.org (Saint Wesonga) Date: Mon, 31 Mar 2025 15:04:14 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds [v2] In-Reply-To: References: Message-ID: <1IR_Yuq93yJxP4o0TGrBIWKltsoW-iMlo0S8_BXe-60=.e2d20272-d61a-4543-899b-8a8d0c8b3d45@github.com> > The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: Clarify that instructions are for cross compilation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24267/files - new: https://git.openjdk.org/jdk/pull/24267/files/c15306a8..8cb94d9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24267&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24267&range=00-01 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24267.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24267/head:pull/24267 PR: https://git.openjdk.org/jdk/pull/24267 From duke at openjdk.org Mon Mar 31 15:04:15 2025 From: duke at openjdk.org (Saint Wesonga) Date: Mon, 31 Mar 2025 15:04:15 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 10:14:54 GMT, Magnus Ihse Bursie wrote: > > Wait, are you saying you can get a native build to work by setting --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO. > > No, it's not. If we could block the `--build` flag, we would. This is the built-in autoconf target/host/build system, that messes with the structure we use in OpenJDK (since we do not do canadian cross builds). > > So if you need to add configure option, this would be the correct one. > > However, we should be able to figure this out by ourselves. This can be solved by a patch in `config.sub` and/or `config.guess`. Thanks for the clarification that the --build flag is undesirable ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766515715 From jlahoda at openjdk.org Mon Mar 31 17:08:09 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 31 Mar 2025 17:08:09 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com> References: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com> Message-ID: On Thu, 27 Mar 2025 18:28:17 GMT, Naoto Sato wrote: >> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. >> >> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. >> >> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. > > src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 69: > >> 67: case 4: break READ; //EOF/Ctrl-D >> 68: case 127: >> 69: //backspace: > > Is it `delete`? I don't think so. Delete is an escape sequence (`\033[3~`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021413402 From jlahoda at openjdk.org Mon Mar 31 17:08:10 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 31 Mar 2025 17:08:10 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com> Message-ID: On Thu, 27 Mar 2025 20:48:22 GMT, Naoto Sato wrote: >> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 198: >> >>> 196: >>> 197: if (it.hasNext()) { >>> 198: out.append("\n\r"); >> >> I understand this is a simple console, but do we want to CR/LF/CRLF based on the platform? > > `line.seprator` system property can be used here When the terminal is in the raw/unprocessed mode, I believe `\n` is only moving the cursor to the next line (without changing the column), and `\r` is doing carriage return. So, to move the cursor to the first character of the next line, both are needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021410890 From naoto at openjdk.org Mon Mar 31 17:20:18 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 31 Mar 2025 17:20:18 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com> Message-ID: On Mon, 31 Mar 2025 17:04:55 GMT, Jan Lahoda wrote: >> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 69: >> >>> 67: case 4: break READ; //EOF/Ctrl-D >>> 68: case 127: >>> 69: //backspace: >> >> Is it `delete`? > > I don't think so. Delete is an escape sequence (`\033[3~`). Hmm, that's interesting. In ASCII control codes, 127 is defined as `Delete` and 08 is defined as `Backspace` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021427938 From duke at openjdk.org Mon Mar 31 17:25:17 2025 From: duke at openjdk.org (David M. Lloyd) Date: Mon, 31 Mar 2025 17:25:17 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 75: > 73: } > 74: continue READ; > 75: case '\033': If this is meant to be platform-agnostic, is it really safe to make these assumptions about the ability to produce or interpret escape codes and to make assumptions about their behavior on the user's terminal? I don't think it would even be safe to assume a single terminal type or interpretation on POSIX-type OSes; that's what things like `terminfo`/`termcap` are supposed to be for, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021436018 From erikj at openjdk.org Mon Mar 31 17:34:40 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 31 Mar 2025 17:34:40 GMT Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v4] In-Reply-To: References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com> Message-ID: On Mon, 31 Mar 2025 14:31:56 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Revertd the STATIC_LIB_CFLAGS fix as it is coverted by JDK-8353272 > > Signed-off-by: Patrick Zhang Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24115#pullrequestreview-2730000582 From erikj at openjdk.org Mon Mar 31 17:38:26 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 31 Mar 2025 17:38:26 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 15:00:08 GMT, Saint Wesonga wrote: > > > Wait, are you saying you can get a native build to work by setting --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO. > > > > > > No, it's not. If we could block the `--build` flag, we would. This is the built-in autoconf target/host/build system, that messes with the structure we use in OpenJDK (since we do not do canadian cross builds). > > So if you need to add configure option, this would be the correct one. > > However, we should be able to figure this out by ourselves. This can be solved by a patch in `config.sub` and/or `config.guess`. > > Thanks for the clarification that the --build flag is undesirable I do not agree with `--build` being undesirable in this specific instance. I agree that it's generally not a flag we want to encourage using, but in this specific case, it's necessary to perform a native build on this platform. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766916854 From erikj at openjdk.org Mon Mar 31 17:44:13 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 31 Mar 2025 17:44:13 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds In-Reply-To: <_v5s02jab1bagTjbypZDPTWbmnihi8Jsu-TBu7nxUFY=.69cd51f9-2d0b-4d2a-a775-cc5454b61dbd@github.com> References: <_v5s02jab1bagTjbypZDPTWbmnihi8Jsu-TBu7nxUFY=.69cd51f9-2d0b-4d2a-a775-cc5454b61dbd@github.com> Message-ID: On Mon, 31 Mar 2025 14:44:23 GMT, Saint Wesonga wrote: > Upon closer inspection, the --build option results in a native build (per the build system) but the ARM64 C++ compiler binary (cl.exe) is actually an x64 binary, so the compiler is running in emulated mode despite the build system thinking that a native build is happening. I'm investigating this in https://bugs.openjdk.org/browse/JDK-8353066 The logic for finding the vcvars.cmd file to setup the Visual Studio environment is hardcoded for x64. You will need to make that logic more generic. > I propose changing the scope of this PR to documenting cross compilation for windows/aarch64 on windows/x64 and fixing the native build in https://bugs.openjdk.org/browse/JDK-8353066 I propose expanding on the doc in this PR just a tad and explaining that to perform a _native_ windows-aarch64 build with Cygwin, you need to set `--build=aarch64-pc-cygwin` as a workaround and to cross compile it, set `--openjdk-target=aarch64-unknown-cygwin`. But it depends on how quickly you expect to fix JDK-8353066. At the very least, the documentation needs to be clear on the difference between a native and a cross compile setup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766930392 From duke at openjdk.org Mon Mar 31 18:11:27 2025 From: duke at openjdk.org (Saint Wesonga) Date: Mon, 31 Mar 2025 18:11:27 GMT Subject: RFR: 8353009: Document target selection flag for Windows AArch64 builds [v3] In-Reply-To: References: Message-ID: > The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness. Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: Add instructions for a native Windows AArch64 build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24267/files - new: https://git.openjdk.org/jdk/pull/24267/files/8cb94d9b..ce4a5914 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24267&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24267&range=01-02 Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24267.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24267/head:pull/24267 PR: https://git.openjdk.org/jdk/pull/24267 From vlivanov at openjdk.org Mon Mar 31 21:51:17 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 31 Mar 2025 21:51:17 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote: > Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. > > It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. > > PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks Thanks for the reviews. > This makes me wonder: @iwanowww what kind of testing have you done to ensure this works correctly? hs-tier1 - hs-tier4 (and up to hs-tier6 as part of larger set of changes). Vector API unit tests (under `test/jdk/jdk/incubator/vector/`) exercise this functionality. >> Is leaving the sources of sleef in share/native the right thing to do? > No, it should move to the least common directory for all platforms where it is needed. In this case, it should move to unix instead of share. Strictly speaking, `src/jdk.incubator.vector/linux/native/libsleef` consists of 3 parts: (a) original SLEEF library sources (under `upstream/` sub-folder); (b) platform-specific generated code (under `generated/`); (c) custom native wrappers used to build `libsleef` library in JDK (under `lib/`). While (c) may be Linux-specific, SLEEF library is cross-platform and covers wide range of platforms [1]. So, strictly speaking, it's (c) which are truly platform-specific and deserve being placed under `[linux|unix]/native`. Moreover, I'm experimenting with SLEEF usage on x86, so it's possible that it will be used on linux-x64/windows-x64 eventually. I'm fine with it either way. But if we don't want to relocate SLEEF sources again rather soon, I suggest to place it under `share/` right away. [1] https://sleef.org/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2767493489 From vlivanov at openjdk.org Mon Mar 31 21:57:07 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 31 Mar 2025 21:57:07 GMT Subject: RFR: 8353217: Build libsleef on macos-aarch64 In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 12:27:23 GMT, Magnus Ihse Bursie wrote: >> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform. >> >> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation. >> >> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`. >> >> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. >> >> Testing: hs-tier1 - hs-tier4, microbenchmarks > > Instead of trying to guide you how to fix this, I made the unification of all libsleef stanzas myself. It is available here: > > https://github.com/openjdk/jdk/commit/04feadda561b2f7a6afff440ab5b4e188361c048 > > That commit assumes that `vector_math_sve.c` should have `$(SVE_CFLAGS)` on mac as well as on linux. If that is not correct, then it needs to be adjusted. Thanks a lot, @magicus! > That commit assumes that vector_math_sve.c should have $(SVE_CFLAGS) on mac as well as on linux. If that is not correct, then it needs to be adjusted. As of now, Apple Silicon doesn't support SVE/SVE2, so I intentionally excluded SVE support on macosx-aarch64. What would be the best way to exclude `vector_math_sve.c` on macosx-aarch64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2767501215