From jlahoda at openjdk.org Wed May 1 11:24:20 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 1 May 2024 11:24:20 GMT Subject: RFR: 8331027: JDK's ct.sym file packs corrupted module-info classes Message-ID: When writing the `ModuleMainClass` attribute, `CreateSymbols` uses an UTF8 entry (incorrect), instead of a Class_info (correct). This patch fixes that. ------------- Commit messages: - 8331027: JDK's ct.sym file packs corrupted module-info classes Changes: https://git.openjdk.org/jdk/pull/19031/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19031&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331027 Stats: 240 lines in 4 files changed: 208 ins; 10 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/19031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19031/head:pull/19031 PR: https://git.openjdk.org/jdk/pull/19031 From syan at openjdk.org Wed May 1 14:46:14 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 1 May 2024 14:46:14 GMT Subject: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect [v2] In-Reply-To: References: Message-ID: > Hi, > > In doc/testing.md file, it says: > > As an example, :tier1 will expand to jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 jtreg:$(TOPDIR)/test/jdk:tier1 jtreg:$(TOPDIR)/test/langtools:tier1 jtreg:$(TOPDIR)/test/nashorn:tier1 jtreg:$(TOPDIR)/test/jaxp:tier1. > > The actual situation is :tier1 doesn't contains test/nashorn:tier1, and the document missed test/lib-test:tier1 > > $ make -n test-tier1 &> test-tier1.log > $ grep "Running test " test-tier1.log > Running test 'jtreg:test/hotspot/jtreg:tier1' > Running test 'jtreg:test/jdk:tier1' > Running test 'jtreg:test/langtools:tier1' > Running test 'jtreg:test/jaxp:tier1' > Running test 'jtreg:test/lib-test:tier1' > > Only change the document, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: deliberately making it shorter and ading ... show that this is not am exhaustive list ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19002/files - new: https://git.openjdk.org/jdk/pull/19002/files/154b0de1..b0277b9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19002&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19002&range=00-01 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/19002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19002/head:pull/19002 PR: https://git.openjdk.org/jdk/pull/19002 From syan at openjdk.org Wed May 1 14:50:52 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 1 May 2024 14:50:52 GMT Subject: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect [v2] In-Reply-To: References:

Message-ID: On Tue, 30 Apr 2024 06:25:46 GMT, David Holmes wrote: > Perhaps we should rephrase this so it is not an exhaustive list that has to be updated if the test groupings change. Suggestion: > > ``` > As an example, :tier1 will expand to include all subcomponent test directories that define `tier1`, for example: > jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 jtreg:$(TOPDIR)/test/jdk:tier1 jtreg:$(TOPDIR)/test/langtools:tier1 .... > ``` Thanks for the review and advice. The doc files has been updated by the advice. @erikj79 @dholmes-ora @magicus ------------- PR Comment: https://git.openjdk.org/jdk/pull/19002#issuecomment-2088574021 From syan at openjdk.org Wed May 1 14:50:53 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 1 May 2024 14:50:53 GMT Subject: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect [v2] In-Reply-To: References:

<5BLnTYx2hjFyOvw3_RQWLDcPwvREkTII1AaLhdQUB7I=.84043d72-429a-4b9a-a119-57f45d239950@github.com> Message-ID: On Fri, 12 Apr 2024 17:39:11 GMT, Joe Darcy wrote: > There should be some quick testing of the new default method on Elements using the VacuousElements implementation; see `test/langtools/tools/javac/processing/model/util/elements` for some examples. @jddarcy I've reorganized the tests in this area a bit, and moved the testing for `DocCommentKind` to a new test, which includes testing the default method, using `VacuousElements` (nice trick, that, by the way.). Although now renamed, the older `TestGetDocComments` is now closer to the original form, with the testing for `getDocCommentKind` being moved to a new test class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-2089096959 From dholmes at openjdk.org Wed May 1 22:23:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 May 2024 22:23:53 GMT Subject: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect [v2] In-Reply-To: References:

Message-ID: On Wed, 3 Apr 2024 02:38:21 GMT, Julian Waters wrote: >> Bumping > >> @TheShermanTanker I tried to help you get this done. I added fixes to a copy of your branch on my personal fork, but then it turned out I could not push them to your branch. :-( >> >> It ended up with me creating a new PR, #18584. As a bonus, I think it might be easier to review with a fresh start. This PR has grown quite heavy with lots of comments and commits. >> >> I hope you don't feel like I'm stealing this away from you. You have done a great job, and shown a lot of patience of carrying this all the way here. But I also got the impression that you would appreciate my assistance in getting the last pieces in place so we can integrate this. > > Not at all, I don't feel like you're stealing this from me. In fact, I should be the one apologising for giving you extra work! Thanks for taking this up, I once again apologise for making you do this instead, I've been very busy since Thursday (working on OpenJDK while in lectures at times), and during my breaks I've been too drained to continue, so i really appreciate your help :) > > I will keep this open until the other Pull Request has been integrated, in case this might still be needed @TheShermanTanker You can close this PR. The bug was fixed with https://github.com/openjdk/jdk/pull/18584 instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-2090226777 From erikj at openjdk.org Thu May 2 12:21:55 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 2 May 2024 12:21:55 GMT Subject: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect [v2] In-Reply-To: References:

Message-ID: <_VcrQuRh1sLyS73fkLR5N29rApinn86gvd-LlC2zB8Q=.a2a9935c-42c5-4920-963f-81ed8732cb60@github.com> On Thu, 2 May 2024 07:03:20 GMT, Adam Sotona wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary directory cleanup. > > test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 1104: > >> 1102: CreateSymbols.EXTENSION = ".class"; >> 1103: >> 1104: deleteRecursively(ctSym); > > Is double deletion needed for some kind of race condition safety? I don't think this is needed. Thanks for noticing, removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19031#discussion_r1587724055 From mdoerr at openjdk.org Thu May 2 14:30:03 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 2 May 2024 14:30:03 GMT Subject: RFR: 8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc [v3] In-Reply-To: <1EgO9Z2UdqtUYN2oNClYl_evpBDw1asCxQRWPk0w_6E=.db209d00-845d-44bc-9ca1-e5c533087638@github.com> References:

<-XeYeJ0OEmauTYsEoSXxzRmQXSKMOLw87GSpqDnEmug=.5cb7e71f-fea6-4a84-8260-5f515d3d3810@github.com>

<18WjPZeDIWkxGIB0BJgyDg5VipCtY4EOlWmIGPWZGCw=.b50cf4a9-61a4-421e-97eb-3dbac94c14f9@github.com> <_xcaF7UUDHA11loD89Dz871vAQgRqMzCdPkahFDfKv8=.a2c6dcbe-5942-4fb7-9d8b-4239ea048e56@github.com> <76P7uKTuqo7IKYr5yBP4Vx1SS0AcEXC_6vDAU6LfIzo=.d939556f-6fab-4009-820b-821376bfdb7c@github.com> <6aR5nvKhz28A1CkxtaAD9CwTjILBjwZrrRwP3988oEc=.72203104-2ae5-40ff-bd87-168b684446e6@ github.com>

<1EgO9Z2UdqtUYN2oNClYl_evpBDw1asCxQRWPk0w_6E=.db209d00-845d-44bc-9ca1-e5c533087638@github.com> Message-ID: On Tue, 30 Apr 2024 16:36:52 GMT, Kim Barrett wrote: >> I will do after labor day and create a PR with this suggested solution in your JDK-8330539. > > I think I still prefer just unconditionally including in globalDefinitions_gcc.hpp. For gcc/clang we are using `-std=c++14` + `-D_GNU_SOURCE` instead of `-std=gnu++14`. I forget exactly why. I don't really want > to be messing with `__STRICT_ANSI__`. https://github.com/openjdk/jdk/pull/19053 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18536#discussion_r1587736142 From jlahoda at openjdk.org Thu May 2 14:34:59 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 2 May 2024 14:34:59 GMT Subject: Integrated: 8331027: JDK's ct.sym file packs corrupted module-info classes In-Reply-To: References: Message-ID: On Wed, 1 May 2024 11:18:36 GMT, Jan Lahoda wrote: > When writing the `ModuleMainClass` attribute, `CreateSymbols` uses an UTF8 entry (incorrect), instead of a Class_info (correct). This patch fixes that. This pull request has now been integrated. Changeset: 8771015d Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/8771015d7e3c4349ad58b58150a49217b1ffb902 Stats: 238 lines in 4 files changed: 206 ins; 10 del; 22 mod 8331027: JDK's ct.sym file packs corrupted module-info classes Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/19031 From kbarrett at openjdk.org Thu May 2 15:11:53 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 2 May 2024 15:11:53 GMT Subject: RFR: 8330539: Use #include instead of -Dalloca'(size)'=__builtin_alloca'(size)' for AIX In-Reply-To: References: Message-ID: On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote: > We need to find a better way to handle alloca on AIX. > > See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257, e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in which three alternatives are suggested. Quoting: > > Let me summarize the choices we have and ask for your vote. > Magnus dislikes the -Dalloca'(size)'=__builtin_alloca'(size)' in flags-cflags.m4 I introduced to get rid of > > #if defined(_AIX) > #include > #endif > > in globalDefinitions_gcc.hpp. > > We have four possible solutions > > 1. Reintroduce > > #if defined(_AIX) > #include > #endif > > in globalDefinitions_gcc.hpp. > > 2. Unconditionally introduce only #include in globalDefinitions_gcc.hpp. This should work for all platforms using this header including the unofficial Windows/gcc Port, although only AIX needs it. > > 3. Add > > #if defined(_AIX) > #include > #endif > > to the sources using alloca(). These are > /hotspot/share/runtime/os.cpp > /hotspot/share/runtime/javaThread.cpp > /hotspot/share/utilities/vmError.cpp > Here we need the AIX condition, because otherwise the classic Windows Build (NTAMD64) fails. > > 4. Replace -Dalloca'(size)'=__builtin_alloca'(size)' in flags-cflags.m4 by -U__STRICT_ANSI__ at the same place. Explanation can also found in https://github.com/openjdk/jdk/pull/18536#discussion_r1583360569 and following. > > I will implement the solution with the most likes and having no dislike. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19053#pullrequestreview-2036034561 From ihse at openjdk.org Thu May 2 21:21:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 2 May 2024 21:21:57 GMT Subject: RFR: 8330539: Use #include instead of -Dalloca'(size)'=__builtin_alloca'(size)' for AIX In-Reply-To: References: Message-ID: On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote: > We need to find a better way to handle alloca on AIX. > > See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257, e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in which three alternatives are suggested. Quoting: > > Let me summarize the choices we have and ask for your vote. > Magnus dislikes the -Dalloca'(size)'=__builtin_alloca'(size)' in flags-cflags.m4 I introduced to get rid of > > #if defined(_AIX) > #include > #endif > > in globalDefinitions_gcc.hpp. > > We have four possible solutions > > 1. Reintroduce > > #if defined(_AIX) > #include > #endif > > in globalDefinitions_gcc.hpp. > > 2. Unconditionally introduce only #include in globalDefinitions_gcc.hpp. This should work for all platforms using this header including the unofficial Windows/gcc Port, although only AIX needs it. > > 3. Add > > #if defined(_AIX) > #include > #endif > > to the sources using alloca(). These are > /hotspot/share/runtime/os.cpp > /hotspot/share/runtime/javaThread.cpp > /hotspot/share/utilities/vmError.cpp > Here we need the AIX condition, because otherwise the classic Windows Build (NTAMD64) fails. > > 4. Replace -Dalloca'(size)'=__builtin_alloca'(size)' in flags-cflags.m4 by -U__STRICT_ANSI__ at the same place. Explanation can also found in https://github.com/openjdk/jdk/pull/18536#discussion_r1583360569 and following. > > I will implement the solution with the most likes and having no dislike. Marked as reviewed by ihse (Reviewer). Looks good to me too. ------------- PR Review: https://git.openjdk.org/jdk/pull/19053#pullrequestreview-2036941518 PR Comment: https://git.openjdk.org/jdk/pull/19053#issuecomment-2091668231 From syan at openjdk.org Thu May 2 21:22:00 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 2 May 2024 21:22:00 GMT Subject: Integrated: 8331331: :tier1 target explanation in doc/testing.md is incorrect In-Reply-To: References: Message-ID: <5l5H7rzYJpzq4rhVRl63dkIZpu1R-6oZxPVXJsa5n6w=.b04fea6c-61dc-4c0d-9544-3f0885226306@github.com> On Mon, 29 Apr 2024 16:14:45 GMT, SendaoYan wrote: > Hi, > > In doc/testing.md file, it says: > > As an example, :tier1 will expand to jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 jtreg:$(TOPDIR)/test/jdk:tier1 jtreg:$(TOPDIR)/test/langtools:tier1 jtreg:$(TOPDIR)/test/nashorn:tier1 jtreg:$(TOPDIR)/test/jaxp:tier1. > > The actual situation is :tier1 doesn't contains test/nashorn:tier1, and the document missed test/lib-test:tier1 > > $ make -n test-tier1 &> test-tier1.log > $ grep "Running test " test-tier1.log > Running test 'jtreg:test/hotspot/jtreg:tier1' > Running test 'jtreg:test/jdk:tier1' > Running test 'jtreg:test/langtools:tier1' > Running test 'jtreg:test/jaxp:tier1' > Running test 'jtreg:test/lib-test:tier1' > > Only change the document, no risk. This pull request has now been integrated. Changeset: 04271dfe Author: SendaoYan Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/04271dfe7a262379944e2a2cf83a98a3a1b78a74 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod 8331331: :tier1 target explanation in doc/testing.md is incorrect Reviewed-by: erikj, dholmes, ihse ------------- PR: https://git.openjdk.org/jdk/pull/19002 From jwaters at openjdk.org Fri May 3 00:40:52 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 3 May 2024 00:40:52 GMT Subject: RFR: 8330539: Use #include instead of -Dalloca'(size)'=__builtin_alloca'(size)' for AIX In-Reply-To: References: Message-ID: On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote: > We need to find a better way to handle alloca on AIX. > > See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257, e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in which three alternatives are suggested. Quoting: > > Let me summarize the choices we have and ask for your vote. > Magnus dislikes the -Dalloca'(size)'=__builtin_alloca'(size)' in flags-cflags.m4 I introduced to get rid of > > #if defined(_AIX) > #include > #endif > > in globalDefinitions_gcc.hpp. > > We have four possible solutions > > 1. Reintroduce > > #if defined(_AIX) > #include > #endif > > in globalDefinitions_gcc.hpp. > > 2. Unconditionally introduce only #include in globalDefinitions_gcc.hpp. This should work for all platforms using this header including the unofficial Windows/gcc Port, although only AIX needs it. > > 3. Add > > #if defined(_AIX) > #include > #endif > > to the sources using alloca(). These are > /hotspot/share/runtime/os.cpp > /hotspot/share/runtime/javaThread.cpp > /hotspot/share/utilities/vmError.cpp > Here we need the AIX condition, because otherwise the classic Windows Build (NTAMD64) fails. > > 4. Replace -Dalloca'(size)'=__builtin_alloca'(size)' in flags-cflags.m4 by -U__STRICT_ANSI__ at the same place. Explanation can also found in https://github.com/openjdk/jdk/pull/18536#discussion_r1583360569 and following. > > I will implement the solution with the most likes and having no dislike. I stand corrected, it seems that MinGW distributions don't have alloca.h in their headers. No worries, the Windows/gcc Port will handle this downstream ------------- PR Comment: https://git.openjdk.org/jdk/pull/19053#issuecomment-2091958780 From jlahoda at openjdk.org Fri May 3 07:21:27 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 May 2024 07:21:27 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 [v5] In-Reply-To: References: Message-ID: > This is a patch that: > a) upgrades the JLine inside the JDK to 3.25.1 > b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend > > Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: > - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 > - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily > > There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: > https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal > the patch is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff > > I've also cleaned the patch a little removing most of the changes for the rename. The result is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - Fixing test. - Cleanup. - Upgrade to 3.26.1 - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1 - Apply suggestions from code review Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - ... and 20 more: https://git.openjdk.org/jdk/compare/130f71ca...01f95c42 ------------- Changes: https://git.openjdk.org/jdk/pull/18142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=04 Stats: 13181 lines in 144 files changed: 5785 ins; 5349 del; 2047 mod Patch: https://git.openjdk.org/jdk/pull/18142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142 PR: https://git.openjdk.org/jdk/pull/18142 From jlahoda at openjdk.org Fri May 3 07:27:09 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 May 2024 07:27:09 GMT Subject: RFR: 8327476: Upgrade JLine to 3.26.1 [v6] In-Reply-To: References: Message-ID: > This is a patch that: > a) upgrades the JLine inside the JDK to 3.25.1 > b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend > > Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: > - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 > - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily > > There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: > https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal > the patch is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff > > I've also cleaned the patch a little removing most of the changes for the rename. The result is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Removing trailing whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18142/files - new: https://git.openjdk.org/jdk/pull/18142/files/01f95c42..9f6509a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142 PR: https://git.openjdk.org/jdk/pull/18142 From jlahoda at openjdk.org Fri May 3 07:27:12 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 May 2024 07:27:12 GMT Subject: RFR: 8327476: Upgrade JLine to 3.26.1 [v5] In-Reply-To: References:

Message-ID: On Fri, 3 May 2024 07:21:27 GMT, Jan Lahoda wrote: >> This is a patch that: >> a) upgrades the JLine inside the JDK to 3.25.1 >> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend >> >> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: >> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 >> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily >> >> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal >> the patch is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff >> >> I've also cleaned the patch a little removing most of the changes for the rename. The result is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: > > - Fixing test. > - Cleanup. > - Upgrade to 3.26.1 > - Merge branch 'master' into jline-upgrade-3.25.1 > - Merge branch 'master' into jline-upgrade-3.25.1 > - Merge branch 'master' into jline-upgrade-3.25.1 > - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 > - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1 > - Apply suggestions from code review > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> > - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 > - ... and 20 more: https://git.openjdk.org/jdk/compare/130f71ca...01f95c42 Update: since JLine 3.26.1 was release, I tried to upgrade to that directly. I made a diff of the relevant files between JLine 3.25.1 and 3.26.1, and applied that diff to our code. Some additional cleanup was done as well, as suggested by Magnus. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18142#issuecomment-2092453108 From jkern at openjdk.org Fri May 3 08:34:57 2024 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 3 May 2024 08:34:57 GMT Subject: Integrated: 8330539: Use #include instead of -Dalloca'(size)'=__builtin_alloca'(size)' for AIX In-Reply-To: References: Message-ID: On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote: > We need to find a better way to handle alloca on AIX. > > See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257, e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in which three alternatives are suggested. Quoting: > > Let me summarize the choices we have and ask for your vote. > Magnus dislikes the -Dalloca'(size)'=__builtin_alloca'(size)' in flags-cflags.m4 I introduced to get rid of > > #if defined(_AIX) > #include > #endif > > in globalDefinitions_gcc.hpp. > > We have four possible solutions > > 1. Reintroduce > > #if defined(_AIX) > #include > #endif > > in globalDefinitions_gcc.hpp. > > 2. Unconditionally introduce only #include in globalDefinitions_gcc.hpp. This should work for all platforms using this header including the unofficial Windows/gcc Port, although only AIX needs it. > > 3. Add > > #if defined(_AIX) > #include > #endif > > to the sources using alloca(). These are > /hotspot/share/runtime/os.cpp > /hotspot/share/runtime/javaThread.cpp > /hotspot/share/utilities/vmError.cpp > Here we need the AIX condition, because otherwise the classic Windows Build (NTAMD64) fails. > > 4. Replace -Dalloca'(size)'=__builtin_alloca'(size)' in flags-cflags.m4 by -U__STRICT_ANSI__ at the same place. Explanation can also found in https://github.com/openjdk/jdk/pull/18536#discussion_r1583360569 and following. > > I will implement the solution with the most likes and having no dislike. This pull request has now been integrated. Changeset: a10845b5 Author: Joachim Kern Committer: Martin Doerr URL: https://git.openjdk.org/jdk/commit/a10845b553fc6fe7e06a0f37ce73fe5f704dc7c4 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod 8330539: Use #include instead of -Dalloca'(size)'=__builtin_alloca'(size)' for AIX Reviewed-by: jwaters, mdoerr, kbarrett, ihse ------------- PR: https://git.openjdk.org/jdk/pull/19053 From ihse at openjdk.org Fri May 3 15:02:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 3 May 2024 15:02:54 GMT Subject: RFR: 8327476: Upgrade JLine to 3.26.1 [v6] In-Reply-To: References:

Message-ID: On Fri, 3 May 2024 07:27:09 GMT, Jan Lahoda wrote: >> This is a patch that: >> a) upgrades the JLine inside the JDK to 3.25.1 >> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend >> >> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: >> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 >> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily >> >> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal >> the patch is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff >> >> I've also cleaned the patch a little removing most of the changes for the rename. The result is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Removing trailing whitespace. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18142#pullrequestreview-2038354269 From syan at openjdk.org Fri May 3 16:07:57 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 3 May 2024 16:07:57 GMT Subject: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect [v2] In-Reply-To: References:

Message-ID: On Wed, 1 May 2024 14:46:14 GMT, SendaoYan wrote: >> Hi, >> >> In doc/testing.md file, it says: >> >> As an example, :tier1 will expand to jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 jtreg:$(TOPDIR)/test/jdk:tier1 jtreg:$(TOPDIR)/test/langtools:tier1 jtreg:$(TOPDIR)/test/nashorn:tier1 jtreg:$(TOPDIR)/test/jaxp:tier1. >> >> The actual situation is :tier1 doesn't contains test/nashorn:tier1, and the document missed test/lib-test:tier1 >> >> $ make -n test-tier1 &> test-tier1.log >> $ grep "Running test " test-tier1.log >> Running test 'jtreg:test/hotspot/jtreg:tier1' >> Running test 'jtreg:test/jdk:tier1' >> Running test 'jtreg:test/langtools:tier1' >> Running test 'jtreg:test/jaxp:tier1' >> Running test 'jtreg:test/lib-test:tier1' >> >> Only change the document, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > deliberately making it shorter and ading ... show that this is not am exhaustive list > /sponsor @magicus Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19002#issuecomment-2093305986 From Suchismith.Roy at ibm.com Mon May 6 09:57:52 2024 From: Suchismith.Roy at ibm.com (Suchismith Roy) Date: Mon, 6 May 2024 09:57:52 +0000 Subject: JDK-8170635 Message-ID: I wanted to discuss regarding https://bugs.openjdk.org/browse/JDK-8170635. Do you have any pointers on moving dladdr() for AIX according to the current JDK23 structure. I think you had suggested one proposition according to JDK11 ? Could we get some more pointers on this proposition ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon May 6 14:36:28 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 6 May 2024 16:36:28 +0200 Subject: JDK-8170635 In-Reply-To: References: Message-ID: Not sure if you meant to address this mail to a specific person. I assume with proposal you mean this: https://mail.openjdk.org/pipermail/build-dev/2016-September/017746.html ? If yes, my proposal was to move dladdr out of the OpenJDK code base into an independent library that would be maintained by IBM, hopefully, and would be a prerequisite for building the JDK. If no, whose proposal did you mean? On Mon, May 6, 2024 at 11:58?AM Suchismith Roy wrote: > I wanted to discuss regarding https://bugs.openjdk.org/browse/JDK-8170635. > > Do you have any pointers on moving dladdr() for AIX according to the > current JDK23 structure. > I think you had suggested one proposition according to JDK11 ? > Could we get some more pointers on this proposition ? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon May 6 16:26:50 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 6 May 2024 18:26:50 +0200 Subject: How do I reliably prevent CDS archive generation during builds? Message-ID: Hi, is there a way to reliably prevent the jvm from being called with -Xshare:dump during build? Often, when I tinker with metaspace or compressed klass pointers, CDS gets broken. During development, that is fine; it is a temporary state. However, if -Xshare:dump is invoked, it may crash the JVM and break the build. I specified --disable-cds-archives and --disable-jvm-feature-link-time-opt. But still, link time optimization step runs and calls the build JVM with -Xshare:dump. Is that a bug? Thanks, Thomas P.S. Also, how is this handled for crossbuilds, where generating shared archives on the build machine makes little sense? -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Mon May 6 17:21:53 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 6 May 2024 10:21:53 -0700 Subject: How do I reliably prevent CDS archive generation during builds? In-Reply-To: References: Message-ID: <787abd8a-0719-4a68-a3e7-db5ec07d5384@oracle.com> On 5/6/24 09:26, Thomas St?fe wrote: > Hi, > > is there a way to reliably prevent the jvm from being called with > -Xshare:dump during build? > > Often, when I tinker with metaspace or compressed klass pointers, CDS > gets broken. During development, that is fine; it is a temporary state. > > However, if -Xshare:dump is invoked, it may crash the JVM and break > the build. > > I specified --disable-cds-archives and > --disable-jvm-feature-link-time-opt. But still, link time optimization > step runs and calls the build JVM with -Xshare:dump. Is that a bug? > I think if you add --disable-generate-classlist to that list of configure arguments, this particular invocation with -Xshare:dump will go away. /Erik > Thanks, Thomas > > P.S. Also, how is this handled for crossbuilds, where generating > shared archives on the build machine makes little sense? > > > From jjg at openjdk.org Mon May 6 17:25:26 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 6 May 2024 17:25:26 GMT Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v65] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update javadoc.1 troff man page ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/e42632a9..9ad5c398 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=64 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=63-64 Stats: 23 lines in 1 file changed: 10 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From vladimir.petko at canonical.com Mon May 6 19:57:16 2024 From: vladimir.petko at canonical.com (Vladimir Petko) Date: Tue, 7 May 2024 07:57:16 +1200 Subject: undefined symbols in libjvm.so Message-ID: Hi, I have recently encountered bugs caused by undefined symbols in libjvm.so[1][2]. The root cause of those issues is the expression in make/autoconf/flags-ldflags.m4: --- if test "x$TOOLCHAIN_TYPE" = xgcc; then EXECUTABLE_LDFLAGS="$EXECUTABLE_LDFLAGS -Wl,--allow-shlib-undefined" ... -- OpenJDK master builds fine after fixing[1] on the following architectures: amd64, i386, armhf, arm64, s390, ppc64el and riscv64. Would it be possible to consider removing -Wl,--allow-shlib-undefined from the build flags? Best Regards, Vladimir. [1] https://bugs.openjdk.org/browse/JDK-8331541 [2] https://bugs.openjdk.org/browse/JDK-8329983 From jjg at openjdk.org Mon May 6 21:01:41 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 6 May 2024 21:01:41 GMT Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v66] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Remove `--no-fonts` from `MISSING_IN_MAN_PAGE` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/9ad5c398..e48ebb53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=65 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=64-65 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From duke at openjdk.org Mon May 6 22:47:23 2024 From: duke at openjdk.org (Volodymyr Paprotski) Date: Mon, 6 May 2024 22:47:23 GMT Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v6] In-Reply-To: References: Message-ID: > Performance. Before: > > Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units > SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 3 6443.934 ? 6.491 ops/s > SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 3 6152.979 ? 4.954 ops/s > SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 3 1895.410 ? 36.979 ops/s > SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 3 1878.955 ? 45.487 ops/s > Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units > o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 3 1357.810 ? 26.584 ops/s > o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 3 1352.119 ? 23.547 ops/s > Benchmark (isMontBench) Mode Cnt Score Error Units > PolynomialP256Bench.benchMultiply false thrpt 3 1746.126 ? 10.970 ops/s > > Performance, no intrinsic: > > Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units > SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 3 6529.839 ? 42.420 ops/s > SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 3 6199.747 ? 133.566 ops/s > SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 3 1973.676 ? 54.071 ops/s > SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 3 1932.127 ? 35.920 ops/s > Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units > o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 3 1355.788 ? 29.858 ops/s > o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 3 1346.523 ? 28.722 ops/s > Benchmark (isMontBench) Mode Cnt Score Error Units > PolynomialP256Bench.benchMultiply true thrpt 3 1919.574 ? 10.591 ops/s > > Performance, **with intrinsics*... Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: Use AffinePoint to exit Montgomery domain Style notes: Affine.equals() - Mismatched fields only appear to be used from testing, perhaps should be moved there instead Affine.getX(boolean)|getY(boolean) - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks - needed to convert Affine to Projective (need to stay in montgomery domain) ECOperations.PointMultiplier - changes could probably be restored to original (since ProjectivePoint handling no longer required) - consider these changes an improvement? (fewer nested classes) - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18583/files - new: https://git.openjdk.org/jdk/pull/18583/files/a1984501..8ff243a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=04-05 Stats: 268 lines in 7 files changed: 89 ins; 147 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/18583.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583 PR: https://git.openjdk.org/jdk/pull/18583 From tanksherman27 at gmail.com Tue May 7 00:57:37 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 7 May 2024 08:57:37 +0800 Subject: How do I reliably prevent CDS archive generation during builds? Message-ID: Hi Thomas, --disable-jvm-feature-link-time-opt is for disabling Link Time Optimization when compiling the JVM itself, as in, requesting LTO from the linker that is linking the JVM. It doesn't have anything to do with what arguments the newly compiled JVM is called with and isn't related to the link optimization pass of the Java classfiles (I am not very familiar with that process), and it is also off by default for most platforms best regards, Julian From jianglizhou at google.com Tue May 7 04:04:56 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 6 May 2024 21:04:56 -0700 Subject: Hermetic Java project meeting In-Reply-To: <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com> References:

<65fdda77-1291-437e-b000-ca0307cf8084@oracle.com> <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com> Message-ID: On Tue, Apr 30, 2024 at 5:42?AM Magnus Ihse Bursie wrote: > > > On 2024-04-26 03:15, Jiangli Zhou wrote: > > On Thu, Apr 25, 2024 at 9:28?AM Magnus Ihse Bursie > > wrote: > >> > >> Just to be more clear, that's with using `objcopy` to localize non-exported symbols for all JDK static libraries and libjvm.a, not just libjvm.a right? > >> > >> Yes. > >> > >> > >> Can you please include the compiler or linker errors on linux/clang? > >> > >> It is a bit tricky. The problem arises at the partial linking step. The problem seem to arise out of how clang converts a request to link into an actual call to ld. I enabled debug code (printing the command line, and running clang with `-v` to get it to print the actual command line used to run ld) and ran it on GHA, where it worked fine. This is how it looks there: > >> > >> WILL_RUN: /usr/bin/clang -v -m64 -r -o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o > >> Ubuntu clang version 14.0.0-1ubuntu1.1 > >> Target: x86_64-pc-linux-gnu > >> Thread model: posix > >> InstalledDir: /usr/bin > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10 > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11 > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12 > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 > >> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 > >> Candidate multilib: .;@m64 > >> Selected multilib: .;@m64 > >> "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/lib/llvm-14/bin/../lib -L/lib -L/usr/lib -r /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o > >> > >> In contrast, on my machine it looks like this: > >> > >> WILL_RUN: /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/clang -v -m64 -r -o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o > >> clang version 13.0.1 > >> Target: x86_64-unknown-linux-gnu > >> Thread model: posix > >> InstalledDir: /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin > >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > >> Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > >> Candidate multilib: .;@m64 > >> Candidate multilib: 32;@m32 > >> Candidate multilib: x32;@mx32 > >> Selected multilib: .;@m64 > >> "/usr/bin/ld" --hash-style=both --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/9 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/../lib -L/lib -L/usr/lib -r /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/9/crtend.o /lib/x86_64-linux-gnu/crtn.o > >> /usr/bin/ld: cannot find -lgcc_s > >> /usr/bin/ld: cannot find -lgcc_s > >> clang-13: error: linker command failed with exit code 1 (use -v to see invocation) > >> > >> I don't understand what makes clang think it should include "-lgcc --as-needed -lgcc_s" and the crt*.o files when doing a partial link. In fact, the entire process on how clang (and gcc) builds up the linker command line is bordering on black magic to me. I think it can be affected by variables set at compile time (at least this was the case for gcc, last I checked), or maybe it picks up some kind of script from the environment. That's why I believe my machine could just be messed up. > >> > >> I could get a bit further by passing "-nodefaultlibs" (or whatever it was), but then the generated .o file were messed up wrt to library symbols and it failed dramatically when trying to do the final link of the static java launcher. > >> > >> > > Looks like you are using /usr/bin/ld and not lld. I haven't run into > > this type of issue. Have you tried -fuse-ld=lld? > > I am not sure why clang insisted on picking up ld and not lld. I remeber > trying with -fuse-ld=lld, and that it did not work either. > Unfortunately, I don't remember exactly what the problems were. > > I started reinstalling my Linux workstation yesterday, but something > went wrong, and it failed so hard that it got semi-bricked by the new > installation, so I need to redo everything from scratch. :-( After that > is done, I'll re-test. Hopefully this was just my old installation that > was too broken. > > > > > >>> > >>> I have also tried to extract all the changes (and only the changes) > >>> related to static build from the hermetic-java-runtime branch (ignoring > >>> the JavaHome/resource loading changes), to see if I could get something > >>> like StaticLink.gmk in mainline. I thought I was doing quite fine, but > >>> after a while I realized my testing was botched since the launcher had > >>> actually loaded the libraries dynamically instead, even though they were > >>> statically linked. :-( I am currently trying to bisect my way thought my > >>> repo to understand where things went wrong. > >> > >> Did you run with `bin/javastatic`? The system automatically detects if the binary contains statically linked native libraries and avoids loading the dynamic libraries. Can you please share which test(s) ran into the library loading issue? I'll see if I can reproduce the problem that you are running into. > >> > >> It was in fact not a problem. I was fooled by an error message. To be sure I was not loading any dynamically linked libraries, I removed the jdk/lib directory. Now the launcher failed, saying something like: > >> > >> "Error: Cannot locate dynamic library libjava.dylib". > >> > >> which was a bit of a jump scare. > >> > >> However, it turned out that it actually tried to load lib/jvm.cfg, and failed in loading this (since I had removed the entire lib directory), and this failure caused the above error message to be printed. When I restored lib/jvm.cfg (but not any dynamic libraries), the launcher worked. > >> > > Sounds like you are running into problems immediately during startup. > > Does the problem occur with just running bin/javastatic using a simple > > HelloWorld? Can you please send me your command line for reproducing? > > Maybe I was not clear enough: I did resolve the problem. > > > For the static Java support, I changed CreateExecutionEnvironment to > > return immediately if it executes statically. jvm.cfg is not loaded. > > Please see https://github.com/openjdk/leyden/blob/c1c5fc686c1452550e1b3663a320fba652248505/src/java.base/unix/native/libjli/java_md.c#L296. > > Sounds like the JLI_IsStaticJDK() check is not working properly in > > your case. > > I've been trying to extract from your port a minimal set of patches that > is needed to get static build to work. In that process, JavaHome and > JLI_IsStaticJDK have been removed. It might be that this issue arised > only in my slimmed-down branch, and not on your leyden branch (at this > point I don't recall exactly). But, we need to fix this separately, > since we must be able to build a static launcher without the hermetic > changes. The JDK and VM code has pre-existing assumptions about the JDK directories and dynamic linking (e.g. the .so). JLI_IsStaticJDK|JLI_SetStaticJDK|JVM_IsStaticJDK|JVM_SetStaticJDK is needed for static JDK support to handle those cases correctly. CreateExecutionEnvironment that I mentioned earlier is one of the examples. I'm quite certain the issue that you are running into is due to the incorrect static check/handling in CreateExecutionEnvironment. > > In my branch, I am only using compile-time #ifdef checks for static vs > dynamic. In the long run, the runtime checks that you have done are a > good thing, but at the moment they are just adding intrusive changes > without providing any benefit -- if we can't reuse .o files between > dynamic and static compilation, there is no point in introducing a > runtime check when we already have a working compile-time check. I haven't seen your branch/code. I'd suggest not going with the #ifdef checks as that's the opposite direction of what we want to achieve. It doesn't seem to be worth your effort to add more #ifdef checks in order to do static linking build work, even those are for temporary testing reasons. > > I did think I correctly changed every dynamic check that you had added > to a compile-time check, so it bewilders me somewhat when you say that > jvm.cfg is not needed in your branch. > > Can you verify and confirm that the static launcher actually works in > your branch, if there is no "lib/jvm.cfg" present? In my /leyden/build/linux-x86_64-server-slowdebug/images/jdk directory: $ mv lib/jvm.cfg lib/jvm.cfg.no_used $ find . | grep jvm.cfg ./lib/jvm.cfg.no_used $ bin/javastatic -cp HelloWorld HelloWorld Thanks! Jiangli > > /Magnus > > > > > > Best, > > Jiangli > > > >> There are several bugs lurking here. For once, the error message is incorrect and should be corrected. Secondly, a statically linked launcher has just a single JVM included and should not have to look for the lib/jvm.cfg file at all. > >> > >> After looking around a bit in the launcher/jli code, my conclusion is that this code will need some additional care and loving attention to make it properly adjusted to function as a static launcher. We can't have a static launcher that tries to load a jvm.cfg file it does not need, and when it fails, complains that it is missing a dynamic library that it should not load. > >> > >> I'll try to get this fixed as part of my efforts to get the static launcher into mainline. > >>> This was done haphazardly in StaticLink.gmk in the hermetic-java-runtime > >>> branch, where an arbitrary subset of external libraries were hard-coded. > >>> Before integration in mainline can be possible, this information needs > >>> to be collected correctly and automatically for all included JDK > >>> libraries. Fortunately, it is not likely to be too hard. I basically > >>> just need to store the information from the LIBS provided to the > >>> NativeCompilation, and pick that up for all static libraries we include > >>> in the static launcher. (A complication is that we need to de-duplicate > >>> the list, and that some libraries are specified using two words, like > >>> "-framework Application" on macos, so it will take some care getting it > >>> right.) > >> > >> Right, currently the hermetic-java-runtime branch specifies a list of hard-coded dependency libraries for linking. One of the goals of the hermetic prototype was avoiding/reducing refactoring/restructuring the existing code whenever possible. The reason is to reduce merge overhead when integrating with new changes from the mainline. We can do the proper refactoring and cleanups when getting the changes into the mainline. > >> > >> That is basically what I am doing right now. I am looking at your prototype and trying to reimplement this functionality properly so that it can be merged into mainline. The first step on that way was to actually get your prototype running. > >> > >> Now I have managed to get a version of your prototype that only includes the minimal set of changes needed to support the static launcher, and that works on mac and linux/gcc. Since your prototype is based on 586396cbb55a31 from March, I am trying to merge the patch with the latest master. This worked fine for macOS, but I hit some unexpected snag on Linux which I'm currently investigating. > >> > >> We have only briefly touched on the spec change topic (for the naming of native libraries) during the zoom meetings. I also agree that we should get that part started now. It's unclear to me if there's any existing blocker for that. > >> > >> I don't think there is. It's just that someone needs to step up and do it. > >> > >> /Magnus From thomas.stuefe at gmail.com Tue May 7 04:08:00 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 7 May 2024 06:08:00 +0200 Subject: How do I reliably prevent CDS archive generation during builds? In-Reply-To: References: Message-ID: Hi Julian, Yes, that confused me too. See here: https://github.com/openjdk/jdk/blob/f308e107ce8b993641ee3d0a0d5d52bf5cd3b94e/make/GenerateLinkOptData.gmk#L76 Cheers, Thomas On Tue, May 7, 2024 at 2:58?AM Julian Waters wrote: > Hi Thomas, > > --disable-jvm-feature-link-time-opt is for disabling Link Time > Optimization when compiling the JVM itself, as in, requesting LTO from > the linker that is linking the JVM. It doesn't have anything to do > with what arguments the newly compiled JVM is called with and isn't > related to the link optimization pass of the Java classfiles (I am not > very familiar with that process), and it is also off by default for > most platforms > > best regards, > Julian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Tue May 7 04:31:28 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 7 May 2024 06:31:28 +0200 Subject: How do I reliably prevent CDS archive generation during builds? In-Reply-To: <787abd8a-0719-4a68-a3e7-db5ec07d5384@oracle.com> References: <787abd8a-0719-4a68-a3e7-db5ec07d5384@oracle.com> Message-ID: Thank you, Eric! On Mon, May 6, 2024 at 7:21?PM wrote: > On 5/6/24 09:26, Thomas St?fe wrote: > > Hi, > > > > is there a way to reliably prevent the jvm from being called with > > -Xshare:dump during build? > > > > Often, when I tinker with metaspace or compressed klass pointers, CDS > > gets broken. During development, that is fine; it is a temporary state. > > > > However, if -Xshare:dump is invoked, it may crash the JVM and break > > the build. > > > > I specified --disable-cds-archives and > > --disable-jvm-feature-link-time-opt. But still, link time optimization > > step runs and calls the build JVM with -Xshare:dump. Is that a bug? > > > I think if you add --disable-generate-classlist to that list of > configure arguments, this particular invocation with -Xshare:dump will > go away. > > /Erik > > > Thanks, Thomas > > > > P.S. Also, how is this handled for crossbuilds, where generating > > shared archives on the build machine makes little sense? > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Suchismith.Roy at ibm.com Tue May 7 08:04:39 2024 From: Suchismith.Roy at ibm.com (Suchismith Roy) Date: Tue, 7 May 2024 08:04:39 +0000 Subject: JDK-8170635 In-Reply-To: References:

Message-ID: Hi Thomas Thank you for the reply. I want to reach out to Erik who was working on this issue. @erik.joelsson at oracle.com Do you also propose the same solution as mentioned by Thomas ? I haven?t worked with resolving build dependencies before, so could I get some guidance on this. May be some old issue that got closed and I can refer the code ? Thanks Suchismith Roy From: Thomas St?fe Date: Monday, 6 May 2024 at 8:06?PM To: Suchismith Roy Cc: build-dev at openjdk.org Subject: [EXTERNAL] Re: JDK-8170635 Not sure if you meant to address this mail to a specific person. I assume with proposal you mean this: https:?//mail.?openjdk.?org/pipermail/build-dev/2016-September/017746.?html ? If yes, my proposal was to move dladdr out of the OpenJDK code ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. Report Suspicious ZjQcmQRYFpfptBannerEnd Not sure if you meant to address this mail to a specific person. I assume with proposal you mean this: https://mail.openjdk.org/pipermail/build-dev/2016-September/017746.html ? If yes, my proposal was to move dladdr out of the OpenJDK code base into an independent library that would be maintained by IBM, hopefully, and would be a prerequisite for building the JDK. If no, whose proposal did you mean? On Mon, May 6, 2024 at 11:58?AM Suchismith Roy > wrote: I wanted to discuss regarding https://bugs.openjdk.org/browse/JDK-8170635. Do you have any pointers on moving dladdr() for AIX according to the current JDK23 structure. I think you had suggested one proposition according to JDK11 ? Could we get some more pointers on this proposition ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Tue May 7 09:19:15 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 7 May 2024 09:19:15 GMT Subject: RFR: 8327476: Upgrade JLine to 3.26.1 [v7] In-Reply-To: References: Message-ID: > This is a patch that: > a) upgrades the JLine inside the JDK to 3.25.1 > b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend > > Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: > - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 > - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily > > There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: > https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal > the patch is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff > > I've also cleaned the patch a little removing most of the changes for the rename. The result is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge branch 'master' into jline-upgrade-3.25.1 - Removing trailing whitespace. - Fixing test. - Cleanup. - Upgrade to 3.26.1 - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1 - ... and 22 more: https://git.openjdk.org/jdk/compare/23a72a1f...5d900a6e ------------- Changes: https://git.openjdk.org/jdk/pull/18142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=06 Stats: 13181 lines in 144 files changed: 5784 ins; 5349 del; 2048 mod Patch: https://git.openjdk.org/jdk/pull/18142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142 PR: https://git.openjdk.org/jdk/pull/18142 From magnus.ihse.bursie at oracle.com Tue May 7 10:36:17 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 7 May 2024 12:36:17 +0200 Subject: undefined symbols in libjvm.so In-Reply-To: References: Message-ID: <64b3b8a6-1047-4f3d-a90c-3d2cfd097bff@oracle.com> Undefined symbols in libjvm.so is no good, and it should not be allowed. However, I am unsure about your analysis. This flag only affect linking of executables, not shared libraries. We do set "-Wl,-z,defs" when linking shared libraries, and this should complain about undefined symbols. /Magnus On 2024-05-06 21:57, Vladimir Petko wrote: > Hi, > > I have recently encountered bugs caused by undefined symbols in > libjvm.so[1][2]. The root cause of those issues is the expression in > make/autoconf/flags-ldflags.m4: > > --- > if test "x$TOOLCHAIN_TYPE" = xgcc; then > EXECUTABLE_LDFLAGS="$EXECUTABLE_LDFLAGS -Wl,--allow-shlib-undefined" > ... > -- > > OpenJDK master builds fine after fixing[1] on the following > architectures: amd64, i386, armhf, arm64, s390, ppc64el and riscv64. > > Would it be possible to consider removing -Wl,--allow-shlib-undefined > from the build flags? > > Best Regards, > Vladimir. > > [1] https://bugs.openjdk.org/browse/JDK-8331541 > [2] https://bugs.openjdk.org/browse/JDK-8329983 From ihse at openjdk.org Tue May 7 10:41:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 7 May 2024 10:41:52 GMT Subject: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326 In-Reply-To: References: Message-ID: On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl, at function` symbol declaration contains a spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that allows linking with undefined symbols > because having the flag on might cause bugs like this one or https://bugs.openjdk.org/browse/JDK-8329983 as the build succeeds even if some symbols are not defined. > Openjdk builds successfully without it on amd64, i386, armhf, arm64, s390, ppc64el and riscv64 with this change[1]. riscv64 build was done locally inside vm: > > Finished building target 'images' in configuration 'linux-riscv64-server-release' > ubuntu at ubuntu:~/jdk$ > > Unfortunately I do not know why it was introduced, so I might be missing something. > I am happy to drop it from this one or move it to a separate issue/pr. > > [1] https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+sourcepub/16076564/+listing-archive-extra I'm not sure why we have `--allow-shlib-undefined`, but changing this should not affect libjvm building. Do you really see a difference in build success/failure depending on that line? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19048#issuecomment-2098040712 From magnus.ihse.bursie at oracle.com Tue May 7 12:26:37 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 7 May 2024 14:26:37 +0200 Subject: Hermetic Java project meeting In-Reply-To: References:

<65fdda77-1291-437e-b000-ca0307cf8084@oracle.com> <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com> Message-ID: <6090f2aa-1480-4706-9281-035579a933af@oracle.com> On 2024-05-07 06:04, Jiangli Zhou wrote: > On Tue, Apr 30, 2024 at 5:42?AM Magnus Ihse Bursie > wrote: >> I am not sure why clang insisted on picking up ld and not lld. I remeber >> trying with -fuse-ld=lld, and that it did not work either. >> Unfortunately, I don't remember exactly what the problems were. >> >> I started reinstalling my Linux workstation yesterday, but something >> went wrong, and it failed so hard that it got semi-bricked by the new >> installation, so I need to redo everything from scratch. :-( After that >> is done, I'll re-test. Hopefully this was just my old installation that >> was too broken. I decided to spend the time to reinstall my machine. Now linking with clang works. Kind of. For some reason, it still picks up binutils ld and not lld, and then -l:libc++.a does not work, but when I replaced it with -l:libstdc++.a it worked just fine. I guess we need to either forcefully add -fuse-ld=lld to our clang compilation lines, or figure out if clang is going to call the binutils or llvm ld, and select the right option. I still find the logic for how clang and gcc locates the default linker to be mostly magic. I guess I need to make a deep dive in understanding this to be able to resolve this properly. > The JDK and VM code has pre-existing assumptions about the JDK > directories and dynamic linking (e.g. the .so). > JLI_IsStaticJDK|JLI_SetStaticJDK|JVM_IsStaticJDK|JVM_SetStaticJDK is > needed for static JDK support to handle those cases correctly. > CreateExecutionEnvironment that I mentioned earlier is one of the > examples. > > I'm quite certain the issue that you are running into is due to the > incorrect static check/handling in CreateExecutionEnvironment. I'll have a look at that, thanks for the pointer. >> In my branch, I am only using compile-time #ifdef checks for static vs >> dynamic. In the long run, the runtime checks that you have done are a >> good thing, but at the moment they are just adding intrusive changes >> without providing any benefit -- if we can't reuse .o files between >> dynamic and static compilation, there is no point in introducing a >> runtime check when we already have a working compile-time check. > I haven't seen your branch/code. I'd suggest not going with the #ifdef > checks as that's the opposite direction of what we want to achieve. It > doesn't seem to be worth your effort to add more #ifdef checks in > order to do static linking build work, even those are for temporary > testing reasons. Okaaaaay... My understanding was that you wanted to push for the quickest possible integration of building a static java launcher into mainline. To do that as fast as possible, we need to use the existing framework for separating statically and dynamically linked libraries, which means doing compile time checks using #ifdefs. Are you saying now that the priorities has changed, and that you want to start by introducing your framework for the runtime lookup if we are static or dynamic? To be honest, I think your prototype is rather hacky in how you implement this, and I reckon that it will require quite a lot of work to be accepted into mainline. I also think you need a CSR for changing the Hotspot/JDK behavior wrt this, which further adds to the process. If you want to go that route instead, then I'll put my work on hold until you have gotten a working solution for the runtime lookup in mainline. I gather this means that there is no real stress for me anymore. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue May 7 12:41:49 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 7 May 2024 05:41:49 -0700 Subject: [External] : RE: JDK-8170635 In-Reply-To: References:

Message-ID: <345f7d5e-693a-4661-8fdf-2b804c59b005@oracle.com> On 5/7/24 01:04, Suchismith Roy wrote: > > Hi Thomas > Thank you for the reply. I want to reach out to Erik who was working > on this issue. > @erik.joelsson at oracle.com Do you > also propose the same solution as mentioned by Thomas ? > This is an almost 8 year old email thread, so I definitely do not remember this discussion. From what I can see I only responded to Volker's counter proposal and added some details on how to solve it that way, and giving it my blessing as a concept. As I'm not affected by how this is solved, I don't have a strong opinion on how to do it, but if I was, I would certainly prefer Volker's solution, with the code still in the JDK repository, to having to deal with a new 3rd party dependency. /Erik > I haven?t worked with resolving build dependencies before, so could I > get some guidance on this. May be some old issue that got closed and I > can refer the code ? > > Thanks > Suchismith Roy > > *From: *Thomas St?fe > *Date: *Monday, 6 May 2024 at 8:06?PM > *To: *Suchismith Roy > *Cc: *build-dev at openjdk.org > *Subject: *[EXTERNAL] Re: JDK-8170635 > > Not sure if you meant to address this mail to a specific person. I > assume with proposal you mean this: > https:?//mail.?openjdk.?org/pipermail/build-dev/2016-September/017746.?html > ? If yes, my proposal was to move dladdr out of the OpenJDK code > > ZjQcmQRYFpfptBannerStart > > *This Message Is From an External Sender * > > This message came from outside your organization. > > > > Report?Suspicious > > ZjQcmQRYFpfptBannerEnd > > Not sure if you meant to address this mail to a specific person. I > assume with proposal you mean this: > https://mail.openjdk.org/pipermail/build-dev/2016-September/017746.html ? > > If yes, my proposal was to move dladdr out of the OpenJDK code base > into an independent library that would be maintained by IBM, > hopefully, and would be a prerequisite for building the JDK. > > If no, whose proposal did you mean? > > On Mon, May 6, 2024 at 11:58?AM Suchismith Roy > wrote: > > I wanted to discuss regarding > https://bugs.openjdk.org/browse/JDK-8170635 > . > Do you have any pointers on moving dladdr() for AIX according to > the current JDK23 structure. > I think you had suggested one proposition according to JDK11 ? > Could we get some more pointers on this proposition ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue May 7 12:48:08 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 7 May 2024 14:48:08 +0200 Subject: JDK-8170635 -- adding a base library to java In-Reply-To: References:

Message-ID: <7b083ada-a538-406e-aac0-bd5e0dad5353@oracle.com> On 2024-05-06 16:36, Thomas St?fe wrote: > Not sure if you meant to address this mail to a specific person. I > assume with proposal you mean this: > https://mail.openjdk.org/pipermail/build-dev/2016-September/017746.html ? > > If yes, my proposal was to move dladdr out of the OpenJDK code base > into an independent library that would be maintained by IBM, > hopefully, and would be a prerequisite for building the JDK. > If no, whose proposal did you mean? Oh, this is an old bug you're picking up Suchismith! I read through the discussion from 2016. It seems that the suggestion to make an external 3rd party library was only supported by Thomas, and that the general agreement among the other participants was that we should have a general, base-level "OSAL" (OS abstraction library) in the JDK, that could be used by both Hotspot and libjli, as well as other JDK libraries. Creating such a library would be a much larger effort than just adding a AIX implementation of dladdr to it, if it existed. The current structure of the JDK does not readily lend itself to such a library, neither in terms of source code layout nor build system. With that said, I do think it would be good if we had such a library. There are more cases than the AIX dladdr issue that is duplicated, like jio_snprintf() and friends. This has actually caused some headaches when doing static builds, since duplication of these functions are not allowed when creating a single linked instance. (The current duplication in dynamic libraries is just ugly and bad programming, not a compilation error.) But it is a much larger question than just fixing an AIX issue. /Magnus From sgehwolf at openjdk.org Tue May 7 16:52:12 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 7 May 2024 16:52:12 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v26] In-Reply-To: References: Message-ID: > Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b eing modularized). > > The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod > java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.internal.vm.compiler.manage... Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits: - Generate the runtime image link diff at jlink time But only do that once the plugin-pipeline has run. The generation is enabled with the hidden option '--generate-linkable-runtime' and the resource pools available at jlink time are being used to generate the diff. - Merge branch 'master' into jdk-8311302-jmodless-link - Use shorter name for the build tool - Review feedback from Erik J. - Remove dependency on CDS which isn't needed anymore - Fix coment - Fix comment - Fix typo - Revert some now unneded build changes - Follow build tools naming convention - ... and 95 more: https://git.openjdk.org/jdk/compare/23a72a1f...67aea4ca ------------- Changes: https://git.openjdk.org/jdk/pull/14787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=25 Stats: 3424 lines in 36 files changed: 3272 ins; 110 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787 From sgehwolf at openjdk.org Tue May 7 16:55:08 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 7 May 2024 16:55:08 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v23] In-Reply-To: References:

<_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com> Message-ID: On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote: >>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going into the direction you had envisioned? Any more blockers? The CSR should be up-to-date and is open for review as well. If no more blockers I'll go over this patch once more and clean it up to prepare for integration. Thanks! >>> >>> Thanks for all the efforts on this. >> >> Thanks for looking at this, Alan! >> >>> I've looked through the latest version. I'm a little bit comfortable with LinkDeltaProducer. One reason it's build tool that is tied tied to code in the jdk.jlink module, and secondly is that it copies runtime-image-link.delta into the run-time image. Our long standing position is that the run-time image is created by jlink rather than a combination of jlink and extra stuff copied in by the build. >>> >>> The part that I like with the current proposal is lib/runtime-image-link.delta as it's less complicated that previous iterations that added a resource into the jimage container. >>> >>> What would you (and @mlchung) think of having jlink generate lib/runtime-image-link.delta as a step between the pipeline and image generation? >> >> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong? > >> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong? > > I think it continues to build time, it's just using some hidden jlink option. So yes, it similar to a previous iteration except that it doesn't run as a plugin the pipeline and the delta goes to the lib directory. > > Let's see what @mlchung says. You've put a lot of work into this so let's see if we can converge to avoid too many more rounds. @AlanBateman @mlchung The latest update now uses the `jlink` build time option `--generate-linkable-runtime` to add needed resources to the `jimage` when a runtime linkable JDK image is being asked for using the configure option. This now runs outside the plugin-pipeline. I think this is what you meant. Sorry it took longer to get back to this... ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2098895722 From jjg at openjdk.org Tue May 7 17:31:29 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 7 May 2024 17:31:29 GMT Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v67] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 91 commits: - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - Remove `--no-fonts` from `MISSING_IN_MAN_PAGE` - Update javadoc.1 troff man page - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - address review feedback, to improve testing of changes to Elements - update copyright years - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - update commonmark-java from 0.21.0 to 0.22.0 - Remove links to `jdk.javadoc` module from `java.compiler` module` - Suppress warnings building tests - ... and 81 more: https://git.openjdk.org/jdk/compare/524aaad9...cc12140a ------------- Changes: https://git.openjdk.org/jdk/pull/16388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=66 Stats: 26446 lines in 243 files changed: 25749 ins; 257 del; 440 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From vpetko at openjdk.org Tue May 7 20:05:52 2024 From: vpetko at openjdk.org (Vladimir Petko) Date: Tue, 7 May 2024 20:05:52 GMT Subject: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326 In-Reply-To: References:

Message-ID: On Tue, 7 May 2024 10:39:31 GMT, Magnus Ihse Bursie wrote: > I'm not sure why we have `--allow-shlib-undefined`, but changing this should not affect libjvm building. Do you really see a difference in build success/failure depending on that line? Hi, Thank you for looking at the issue!!! Removing the setting should just prevent typos like this from getting into code base. Maybe there was some historical issue that was addressed by it. I did a rebuild on all arches I had access to validate that master does not have any more undefined symbols. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19048#issuecomment-2099206184 From vladimir.petko at canonical.com Tue May 7 20:55:22 2024 From: vladimir.petko at canonical.com (Vladimir Petko) Date: Wed, 8 May 2024 08:55:22 +1200 Subject: undefined symbols in libjvm.so In-Reply-To: <64b3b8a6-1047-4f3d-a90c-3d2cfd097bff@oracle.com> References: <64b3b8a6-1047-4f3d-a90c-3d2cfd097bff@oracle.com> Message-ID: Hi, This is probably an edge-case with assembly-defined symbols. -Wl,z,defs prevents linking a shared library with undefined imports, but does nothing about symbols exported by the library itself that are undefined. -Wl,--allow-shlib-undefined allows linking executable against such library as long as it does not use any of the undefined symbols. I have made a small sample[1] to illustrate the point. Best Regards, Vladimir. [1] https://github.com/vpa1977/linksample On Tue, May 7, 2024 at 10:36?PM Magnus Ihse Bursie wrote: > > Undefined symbols in libjvm.so is no good, and it should not be allowed. > However, I am unsure about your analysis. This flag only affect linking > of executables, not shared libraries. We do set "-Wl,-z,defs" when > linking shared libraries, and this should complain about undefined symbols. > > /Magnus > > On 2024-05-06 21:57, Vladimir Petko wrote: > > Hi, > > > > I have recently encountered bugs caused by undefined symbols in > > libjvm.so[1][2]. The root cause of those issues is the expression in > > make/autoconf/flags-ldflags.m4: > > > > --- > > if test "x$TOOLCHAIN_TYPE" = xgcc; then > > EXECUTABLE_LDFLAGS="$EXECUTABLE_LDFLAGS -Wl,--allow-shlib-undefined" > > ... > > -- > > > > OpenJDK master builds fine after fixing[1] on the following > > architectures: amd64, i386, armhf, arm64, s390, ppc64el and riscv64. > > > > Would it be possible to consider removing -Wl,--allow-shlib-undefined > > from the build flags? > > > > Best Regards, > > Vladimir. > > > > [1] https://bugs.openjdk.org/browse/JDK-8331541 > > [2] https://bugs.openjdk.org/browse/JDK-8329983 From darcy at openjdk.org Tue May 7 21:18:10 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 May 2024 21:18:10 GMT Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v56] In-Reply-To: References:

<5BLnTYx2hjFyOvw3_RQWLDcPwvREkTII1AaLhdQUB7I=.84043d72-429a-4b9a-a119-57f45d239950@github.com> Message-ID: <2yZ6XIyYiWxsxC0IEVoIxGh69F39u1bNKfQFYlGrUkc=.85ec054c-1714-4438-9999-c58527f7d509@github.com> On Wed, 1 May 2024 20:40:00 GMT, Jonathan Gibbons wrote: > > There should be some quick testing of the new default method on Elements using the VacuousElements implementation; see `test/langtools/tools/javac/processing/model/util/elements` for some examples. > > @jddarcy I've reorganized the tests in this area a bit, and moved the testing for `DocCommentKind` to a new test, which includes testing the default method, using `VacuousElements` (nice trick, that, by the way.). Although now renamed, the older `TestGetDocComments` is now closer to the original form, with the testing for `getDocCommentKind` being moved to a new test class. Creating one VacuousElements was preferable to creating one each time a new default method was added :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-2099322156 From darcy at openjdk.org Tue May 7 21:35:06 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 May 2024 21:35:06 GMT Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v67] In-Reply-To: References:

Message-ID: On Tue, 7 May 2024 17:31:29 GMT, Jonathan Gibbons wrote: >> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. >> >> Notable features: >> >> * support for `///` documentation comments in `JavaTokenizer` >> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library >> * updates to `DocCommentParser` to treat `///` comments as Markdown >> * updates to the standard doclet to render Markdown comments in HTML > > Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 91 commits: > > - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 > - Remove `--no-fonts` from `MISSING_IN_MAN_PAGE` > - Update javadoc.1 troff man page > - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 > - address review feedback, to improve testing of changes to Elements > - update copyright years > - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 > - update commonmark-java from 0.21.0 to 0.22.0 > - Remove links to `jdk.javadoc` module from `java.compiler` module` > - Suppress warnings building tests > - ... and 81 more: https://git.openjdk.org/jdk/compare/524aaad9...cc12140a The `javax.lang.model` portions look good; the reminder needs review by others. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-2044237602 From erikj at openjdk.org Wed May 8 01:07:23 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 8 May 2024 01:07:23 GMT Subject: RFR: 8331886: Allow markdown src file overrides Message-ID: For c, c++ and java source files, we have a built in system for letting more specific files override if there are multiple files with the same name found, by letting the first found file with a given name override any later found files with that name. This is typically used for OS specific variants or when needing to override a source file with a file from a custom source set. We would like to make it possible to do the same for markdown files used to generate man pages. This will not have an immediate use i OpenJDK, but is needed for a custom override in proprietary code. The change in Docs.gmk removes unnecessary extra loops so that SetupProcessMarkdown is called only once per module. This is necessary for the override mechanism to kick in for each module src set. The logic in ProcessMarkdown.gmk is more or less copied from SetupNativeCompilation. ------------- Commit messages: - JDK-8331886 Changes: https://git.openjdk.org/jdk/pull/19132/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19132&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331886 Stats: 77 lines in 2 files changed: 16 ins; 11 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/19132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19132/head:pull/19132 PR: https://git.openjdk.org/jdk/pull/19132 From djelinski at openjdk.org Wed May 8 06:40:53 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 8 May 2024 06:40:53 GMT Subject: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326 In-Reply-To: References: Message-ID: <_JH_hctBPUlUt3puwBIoDzippE90OCMViJDiPV44u4w=.43bb386b-53ed-4f79-9b0f-f24c4dae39f5@github.com> On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl, at function` symbol declaration contains a spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that allows linking with undefined symbols > because having the flag on might cause bugs like this one or https://bugs.openjdk.org/browse/JDK-8329983 as the build succeeds even if some symbols are not defined. > Openjdk builds successfully without it on amd64, i386, armhf, arm64, s390, ppc64el and riscv64 with this change[1]. riscv64 build was done locally inside vm: > > Finished building target 'images' in configuration 'linux-riscv64-server-release' > ubuntu at ubuntu:~/jdk$ > > Unfortunately I do not know why it was introduced, so I might be missing something. > I am happy to drop it from this one or move it to a separate issue/pr. > > [1] https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+sourcepub/16076564/+listing-archive-extra Looks good to me. Mach5 and GHA agree that we don't need explicit `allow-shlib-undefined` anymore. On a side note, our use of `.type` appears to serve no purpose other than introducing errors. Perhaps we could remove all the useless `.type` lines in a follow up PR. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19048#pullrequestreview-2044752790 From sgehwolf at openjdk.org Wed May 8 09:32:05 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 May 2024 09:32:05 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v26] In-Reply-To: References:

Message-ID: On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized). >> >> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime. >> >> Basic usage example: >> >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) >> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) >> $ ls ../linux-x86_64-server-release/images/jdk/jmods >> java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod >> java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod >> java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod >> java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.i... > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits: > > - Generate the runtime image link diff at jlink time > > But only do that once the plugin-pipeline has run. The generation is > enabled with the hidden option '--generate-linkable-runtime' and > the resource pools available at jlink time are being used to generate > the diff. > - Merge branch 'master' into jdk-8311302-jmodless-link > - Use shorter name for the build tool > - Review feedback from Erik J. > - Remove dependency on CDS which isn't needed anymore > - Fix coment > - Fix comment > - Fix typo > - Revert some now unneded build changes > - Follow build tools naming convention > - ... and 95 more: https://git.openjdk.org/jdk/compare/23a72a1f...67aea4ca GHA test failures [gc/shenandoah/oom/TestThreadFailure](https://github.com/jerboaa/jdk/actions/runs/8989206765#user-content-gc_shenandoah_oom_testthreadfailure) on Mac x86_64 and [java/util/zip/ZipFile/ZipSourceCache](https://github.com/jerboaa/jdk/actions/runs/8989206765#user-content-java_util_zip_zipfile_zipsourcecache) on Windows x86_64 seem unrelated to this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2100159861 From ihse at openjdk.org Wed May 8 10:12:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 10:12:52 GMT Subject: RFR: 8331886: Allow markdown src file overrides In-Reply-To: References: Message-ID: On Wed, 8 May 2024 01:02:41 GMT, Erik Joelsson wrote: > For c, c++ and java source files, we have a built in system for letting more specific files override if there are multiple files with the same name found, by letting the first found file with a given name override any later found files with that name. This is typically used for OS specific variants or when needing to override a source file with a file from a custom source set. We would like to make it possible to do the same for markdown files used to generate man pages. > > This will not have an immediate use i OpenJDK, but is needed for a custom override in proprietary code. > > The change in Docs.gmk removes unnecessary extra loops so that SetupProcessMarkdown is called only once per module. This is necessary for the override mechanism to kick in for each module src set. > > The logic in ProcessMarkdown.gmk is more or less copied from SetupNativeCompilation. make/common/ProcessMarkdown.gmk line 43: > 41: # Only continue if this target file hasn't been processed already. This lets > 42: # the first found source file override any other with the same name. > 43: $$(call PrintVar, $1_$2_INPUT_FILE) Left-over debug code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19132#discussion_r1593782745 From ihse at openjdk.org Wed May 8 10:15:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 10:15:55 GMT Subject: RFR: 8331886: Allow markdown src file overrides In-Reply-To: References: Message-ID: On Wed, 8 May 2024 01:02:41 GMT, Erik Joelsson wrote: > For c, c++ and java source files, we have a built in system for letting more specific files override if there are multiple files with the same name found, by letting the first found file with a given name override any later found files with that name. This is typically used for OS specific variants or when needing to override a source file with a file from a custom source set. We would like to make it possible to do the same for markdown files used to generate man pages. > > This will not have an immediate use i OpenJDK, but is needed for a custom override in proprietary code. > > The change in Docs.gmk removes unnecessary extra loops so that SetupProcessMarkdown is called only once per module. This is necessary for the override mechanism to kick in for each module src set. > > The logic in ProcessMarkdown.gmk is more or less copied from SetupNativeCompilation. Looks good (apart from the PrintVar) This was particularly hard to review, since neither Github nor Webrev could make any sense of this. For other reviewers, I can add that the only substantial change in ProcessMarkdown.gmk is wrapping the entire function body in a `ifeq ($$($1_$2_OUTPUT_FILE_PROCESSED), )` check (and updating this variable upon entry). ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19132#pullrequestreview-2045243623 PR Comment: https://git.openjdk.org/jdk/pull/19132#issuecomment-2100237486 From ihse at openjdk.org Wed May 8 11:05:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 11:05:54 GMT Subject: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326 In-Reply-To: References: Message-ID: On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl, at function` symbol declaration contains a spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that allows linking with undefined symbols > because having the flag on might cause bugs like this one or https://bugs.openjdk.org/browse/JDK-8329983 as the build succeeds even if some symbols are not defined. > Openjdk builds successfully without it on amd64, i386, armhf, arm64, s390, ppc64el and riscv64 with this change[1]. riscv64 build was done locally inside vm: > > Finished building target 'images' in configuration 'linux-riscv64-server-release' > ubuntu at ubuntu:~/jdk$ > > Unfortunately I do not know why it was introduced, so I might be missing something. > I am happy to drop it from this one or move it to a separate issue/pr. > > [1] https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+sourcepub/16076564/+listing-archive-extra Ok, I think I'm understanding this better now. The error occurs since the `.type`, `.globl` and `.hidden` directives do not match -- we define the global symbol to be `SafeFetch32_impl` but then we set the type of the non-existing symbol `_SafeFetch32_impl`. Somehow this tricks the linker into accepting this as an undefined symbol. The `.type` directive is not without purpose -- it sets the type of the symbol to be a function. If omitted, the type will be `NOTYPE`. Apparently this does not break the program but there is no reason to remove the `.type` directives. Instead, we should have a common macro, something like this: #define DECLARE_FUNC(func) \ .globl func ; \ .hidden func ; \ .type func, at function ; \ func: in a shared file, and include and use it for all symbols in our hotspot assembly files. I was thinking somewhat along those lines last time I was poking around there (when introducing .hidden for the removal of the hotspot map files), but never really got around to it. This bug really shows why we should do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19048#issuecomment-2100322142 From ihse at openjdk.org Wed May 8 11:10:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 11:10:52 GMT Subject: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326 In-Reply-To: References: Message-ID: On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl, at function` symbol declaration contains a spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that allows linking with undefined symbols > because having the flag on might cause bugs like this one or https://bugs.openjdk.org/browse/JDK-8329983 as the build succeeds even if some symbols are not defined. > Openjdk builds successfully without it on amd64, i386, armhf, arm64, s390, ppc64el and riscv64 with this change[1]. riscv64 build was done locally inside vm: > > Finished building target 'images' in configuration 'linux-riscv64-server-release' > ubuntu at ubuntu:~/jdk$ > > Unfortunately I do not know why it was introduced, so I might be missing something. > I am happy to drop it from this one or move it to a separate issue/pr. > > [1] https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+sourcepub/16076564/+listing-archive-extra So, after sleeping on this, here is my analysis/verdict: 1) The fix on renaming the `.type` directive looks good. This is the actual bug fix. 2) We can remove `--allow-shlib-undefined`. That just overrides `--no-allow-shlib- undefined`, which has been the default for years and years, and there is no good reason to have it. It is not strictly related to the bug fix per se, but we can do that in this PR as well to keep things simpler. 3) The reason this could happen was since we used assembler code. A similar problem in C++ code would not have been allowed by the compiler. 4) If we introduce a common macro as I suggest, we can avoid this ever happening again. So while the linker cannot guarantee the consistency when linking libjvm.so (which I really would have liked), by using a stricter scheme when defining symbols in assembly code, we can make sure to avoid it. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19048#pullrequestreview-2045354117 From ihse at openjdk.org Wed May 8 11:37:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 11:37:52 GMT Subject: RFR: 8331541: [i386] linking with libjvm.so fails after JDK-8283326 In-Reply-To: References: Message-ID: On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl, at function` symbol declaration contains a spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that allows linking with undefined symbols > because having the flag on might cause bugs like this one or https://bugs.openjdk.org/browse/JDK-8329983 as the build succeeds even if some symbols are not defined. > Openjdk builds successfully without it on amd64, i386, armhf, arm64, s390, ppc64el and riscv64 with this change[1]. riscv64 build was done locally inside vm: > > Finished building target 'images' in configuration 'linux-riscv64-server-release' > ubuntu at ubuntu:~/jdk$ > > Unfortunately I do not know why it was introduced, so I might be missing something. > I am happy to drop it from this one or move it to a separate issue/pr. > > [1] https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+sourcepub/16076564/+listing-archive-extra I created https://bugs.openjdk.org/browse/JDK-8331921 to track setting up proper assembly functions consistently. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19048#issuecomment-2100375665 From erikj at openjdk.org Wed May 8 14:09:16 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 8 May 2024 14:09:16 GMT Subject: RFR: 8331939: Add custom hook for TestImage Message-ID: We need a custom hook in TestImage.gmk to modify behavior when building with custom source. ------------- Commit messages: - JDK-8331939 Changes: https://git.openjdk.org/jdk/pull/19139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331939 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19139/head:pull/19139 PR: https://git.openjdk.org/jdk/pull/19139 From erikj at openjdk.org Wed May 8 14:29:18 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 8 May 2024 14:29:18 GMT Subject: RFR: 8331886: Allow markdown src file overrides [v2] In-Reply-To: References: Message-ID: > For c, c++ and java source files, we have a built in system for letting more specific files override if there are multiple files with the same name found, by letting the first found file with a given name override any later found files with that name. This is typically used for OS specific variants or when needing to override a source file with a file from a custom source set. We would like to make it possible to do the same for markdown files used to generate man pages. > > This will not have an immediate use i OpenJDK, but is needed for a custom override in proprietary code. > > The change in Docs.gmk removes unnecessary extra loops so that SetupProcessMarkdown is called only once per module. This is necessary for the override mechanism to kick in for each module src set. > > The logic in ProcessMarkdown.gmk is more or less copied from SetupNativeCompilation. Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Remove debug printing - Merge branch 'master' into JDK-8331886-override-markdown - JDK-8331886 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19132/files - new: https://git.openjdk.org/jdk/pull/19132/files/0bc0a668..17fee013 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19132&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19132&range=00-01 Stats: 15 lines in 2 files changed: 11 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19132/head:pull/19132 PR: https://git.openjdk.org/jdk/pull/19132 From ihse at openjdk.org Wed May 8 14:57:16 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 14:57:16 GMT Subject: RFR: 8331921: Hotspot assembler files should use common logic to setup exported functions Message-ID: As seen in [JDK-8331541](https://bugs.openjdk.org/browse/JDK-8331541), if we are not consistently setting all assembler directives correctly, we can get errors that are not detected by the linker. We should stop duplicating this code and create a unified macro to properly setup functions, and use it everywhere. ------------- Commit messages: - Fix copyright headers - Fix building on macos/aarch64 - Use % instead of @ due to arm assembler - 8331921: Hotspot assembler files should use common logic to setup exported functions Changes: https://git.openjdk.org/jdk/pull/19138/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331921 Stats: 604 lines in 22 files changed: 124 ins; 347 del; 133 mod Patch: https://git.openjdk.org/jdk/pull/19138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19138/head:pull/19138 PR: https://git.openjdk.org/jdk/pull/19138 From ihse at openjdk.org Wed May 8 14:57:16 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 14:57:16 GMT Subject: RFR: 8331921: Hotspot assembler files should use common logic to setup exported functions In-Reply-To: References: Message-ID: <6-pc1tNFv2LheyrQM4QcQyF0BveywaPWGihMx5lAswA=.001ce14c-bd15-4a36-a77f-3e6bad762658@github.com> On Wed, 8 May 2024 13:30:59 GMT, Magnus Ihse Bursie wrote: > As seen in [JDK-8331541](https://bugs.openjdk.org/browse/JDK-8331541), if we are not consistently setting all assembler directives correctly, we can get errors that are not detected by the linker. > > We should stop duplicating this code and create a unified macro to properly setup functions, and use it everywhere. When making a build comparison, the build result was identical on Windows (of course), and macOS. On linux/x64 and linux/aarch64, there was a slight difference, in that a few functions did not properly set `.type`, so they appeared as `NOTYPE` instead of `FUNC` in the symbol table. I have not done comparison builds for other linux platforms, but I assume that GHA passing is good enough. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19138#issuecomment-2100776636 From ihse at openjdk.org Wed May 8 14:57:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 14:57:56 GMT Subject: RFR: 8331886: Allow markdown src file overrides [v2] In-Reply-To: References:

Message-ID: On Wed, 8 May 2024 14:29:18 GMT, Erik Joelsson wrote: >> For c, c++ and java source files, we have a built in system for letting more specific files override if there are multiple files with the same name found, by letting the first found file with a given name override any later found files with that name. This is typically used for OS specific variants or when needing to override a source file with a file from a custom source set. We would like to make it possible to do the same for markdown files used to generate man pages. >> >> This will not have an immediate use i OpenJDK, but is needed for a custom override in proprietary code. >> >> The change in Docs.gmk removes unnecessary extra loops so that SetupProcessMarkdown is called only once per module. This is necessary for the override mechanism to kick in for each module src set. >> >> The logic in ProcessMarkdown.gmk is more or less copied from SetupNativeCompilation. > > Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Remove debug printing > - Merge branch 'master' into JDK-8331886-override-markdown > - JDK-8331886 Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19132#pullrequestreview-2045917930 From ihse at openjdk.org Wed May 8 15:01:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 15:01:07 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v26] In-Reply-To: References:

Message-ID: On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote: >> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - disable unused-function warnings; add log msg >> - minor > > Thank you for the update and for working on this in general. > > I've started working on JDK-8329816, preparing the change for the SLEEF specific part of the change. Specifically, I'm currently planning on including the three SLEEF header files, the README and a legal/sleef.md file in that change. Let me know if you have any thoughts/concerns. > > Also, just for my understanding, would love to understand your thoughts on the future here (I apologize if this was already discussed elsewhere): > > It seem like SLEEF is (sort of) limited to linux at this point (the SLEEF README mentions that "Due to limited test capacities, SLEEF is currently only officially supported on Linux with gcc or llvm/clang." ). That same README does, however, indicate good test coverage on several architectures in addition to aarch64 (including x86_64, PPC, RISC-V). With that in mind, it looks like we could potentially use SLEEF for other architectures on linux in the future? And potentially additional operating systems as well? Hey @vidmik , I just added inline header file for riscv64, hope to help avoid go through the legal process for arm and riscv header files separately. For implementation on riscv64, I will put it in another pr. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2101055673 From mli at openjdk.org Wed May 8 17:41:23 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 8 May 2024 17:41:23 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v6] In-Reply-To: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: <2VxBcA-0qxX3N35u5vnKyT920nTH5llf2k5_sKQcqT8=.23823400-536f-458e-baf7-53f99547abc4@github.com> > Hi, > Can you help to review the patch? > This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). > > Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. > Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. > > Besides of the code changes, one important task is to handle the legal process. > > Thanks! > > ## Performance > NOTE: > * `Src` means implementation in this pr, i.e. without depenency on external sleef. > * `Disabled` means disable intrinsics by `-XX:-UseVectorStubs` > * `system_sleef` means implementation in [previous pr 18294](https://github.com/openjdk/jdk/pull/18294), i.e. build and run jdk with depenency on external sleef. > > Basically, the perf data below shows that > * this implementation has better performance than previous version in [pr 18294](https://github.com/openjdk/jdk/pull/18294), > * and both sleef versions has much better performance compared with non-sleef version. > > |Benchmark |(size)|Src |Units|system_sleef|(system_sleef-Src)/Src|Diabled |(Disable-Src)/Src| > |------------------------------|------|---------|-----|------------|----------------------|---------|-----------------| > |3472:Double128Vector.ACOS |1024 |8546.842 |ns/op|8516.007 |-0.004 |16799.273|0.966 | > |3473:Double128Vector.ASIN |1024 |6864.656 |ns/op|6987.328 |0.018 |16602.442|1.419 | > |3474:Double128Vector.ATAN |1024 |11489.255|ns/op|12261.800 |0.067 |26329.320|1.292 | > |3475:Double128Vector.ATAN2 |1024 |16661.170|ns/op|17234.472 |0.034 |42084.100|1.526 | > |3476:Double128Vector.CBRT |1024 |18999.387|ns/op|20298.458 |0.068 |35998.688|0.895 | > |3477:Double128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054 |24420.692|0.734 | > |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003 |21343.863|0.749 | > |3479:Double128Vector.EXP |1024 |4553.108 |ns/op|4777.638 |0.049 |20155.903|3.427 | > |3480:D... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: update header files for arm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18605/files - new: https://git.openjdk.org/jdk/pull/18605/files/bd9c0931..36415c34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18605&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18605&range=04-05 Stats: 20 lines in 2 files changed: 14 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18605/head:pull/18605 PR: https://git.openjdk.org/jdk/pull/18605 From mikael at openjdk.org Wed May 8 18:06:51 2024 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 8 May 2024 18:06:51 GMT Subject: RFR: 8331939: Add custom hook for TestImage In-Reply-To: References: Message-ID: <3JORgqNqm_4oofeWc7K_h6jwR3M734DoDd1Iq86fhGs=.c8034f5f-5560-4f26-baf4-e4e39a7f509f@github.com> On Wed, 8 May 2024 14:03:48 GMT, Erik Joelsson wrote: > We need a custom hook in TestImage.gmk to modify behavior when building with custom source. Marked as reviewed by mikael (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19139#pullrequestreview-2046326105 From stuefe at openjdk.org Wed May 8 18:12:52 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 8 May 2024 18:12:52 GMT Subject: RFR: 8331942: On Linux aarch64, CDS archives should be using 64K alignment by default In-Reply-To: <3_HS3C3-Z0JDz4yt42FX0Y3fhdcETCz0lHGAJBOh6ZI=.48fc9fc2-8ffe-4cf5-a46d-61882ab408bd@github.com> References: <4-4Y0kUGd0M1mvIy16XdBFWZfmnu1AlC8ufi5aoNT6c=.d262020d-00ea-4093-9fc6-5b2d726ca676@github.com> <3_HS3C3-Z0JDz4yt42FX0Y3fhdcETCz0lHGAJBOh6ZI=.48fc9fc2-8ffe-4cf5-a46d-61882ab408bd@github.com> Message-ID: On Wed, 8 May 2024 17:01:26 GMT, Andrew Haley wrote: > This is obviously correct. Otherwise, the CDS archive will only work if the JDK happens to have been built on a machine with greater or equal page size. > > Does the default `compatible-cds-alignment=false` make any sense anywhere on other platforms, though? We might simply make compatibility the default. The configure option is also evaluated for MacOS x64 to enforce an alignment of 16K, to be able to run on MacOS aarch64 in Rosetta. Seeing how MacOS x64 is not really important anymore, and losses due to 16K alignment are small, I'd be fine with setting the default to compatible. It would be a simpler patch, certainly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19142#issuecomment-2101138971 From Suchismith.Roy at ibm.com Wed May 8 18:16:28 2024 From: Suchismith.Roy at ibm.com (Suchismith Roy) Date: Wed, 8 May 2024 18:16:28 +0000 Subject: JDK-8170635 -- adding a base library to java In-Reply-To: <7b083ada-a538-406e-aac0-bd5e0dad5353@oracle.com> References:

<7b083ada-a538-406e-aac0-bd5e0dad5353@oracle.com> Message-ID: Thanks for the reply @Magnus Ihse Bursie Is there any example of PRs which create such libraries that I can refer to ? Is OSAL similar to how os.cpp is defined and respective platforms implement them ? From: Magnus Ihse Bursie Date: Tuesday, 7 May 2024 at 6:18?PM To: Thomas St?fe , Suchismith Roy Cc: build-dev at openjdk.org Subject: [EXTERNAL] Re: JDK-8170635 -- adding a base library to java On 2024-05-06 16:36, Thomas St?fe wrote: > Not sure if you meant to address this mail to a specific person. I > assume with proposal you mean this: > https://mail.openjdk.org/pipermail/build-dev/2016-September/017746.html ? > > If yes, my proposal was to move dladdr out of the OpenJDK code base > into an independent library that would be maintained by IBM, > hopefully, and would be a prerequisite for building the JDK. > If no, whose proposal did you mean? Oh, this is an old bug you're picking up Suchismith! I read through the discussion from 2016. It seems that the suggestion to make an external 3rd party library was only supported by Thomas, and that the general agreement among the other participants was that we should have a general, base-level "OSAL" (OS abstraction library) in the JDK, that could be used by both Hotspot and libjli, as well as other JDK libraries. Creating such a library would be a much larger effort than just adding a AIX implementation of dladdr to it, if it existed. The current structure of the JDK does not readily lend itself to such a library, neither in terms of source code layout nor build system. With that said, I do think it would be good if we had such a library. There are more cases than the AIX dladdr issue that is duplicated, like jio_snprintf() and friends. This has actually caused some headaches when doing static builds, since duplication of these functions are not allowed when creating a single linked instance. (The current duplication in dynamic libraries is just ugly and bad programming, not a compilation error.) But it is a much larger question than just fixing an AIX issue. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Wed May 8 22:00:57 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 8 May 2024 22:00:57 GMT Subject: Integrated: 8331939: Add custom hook for TestImage In-Reply-To: References: Message-ID: On Wed, 8 May 2024 14:03:48 GMT, Erik Joelsson wrote: > We need a custom hook in TestImage.gmk to modify behavior when building with custom source. This pull request has now been integrated. Changeset: 0d1216c7 Author: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/0d1216c7a1dc215550ac769afc21dea91c638215 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8331939: Add custom hook for TestImage Reviewed-by: mikael ------------- PR: https://git.openjdk.org/jdk/pull/19139 From erikj at openjdk.org Wed May 8 22:00:57 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 8 May 2024 22:00:57 GMT Subject: Integrated: 8331886: Allow markdown src file overrides In-Reply-To: References: Message-ID: On Wed, 8 May 2024 01:02:41 GMT, Erik Joelsson wrote: > For c, c++ and java source files, we have a built in system for letting more specific files override if there are multiple files with the same name found, by letting the first found file with a given name override any later found files with that name. This is typically used for OS specific variants or when needing to override a source file with a file from a custom source set. We would like to make it possible to do the same for markdown files used to generate man pages. > > This will not have an immediate use i OpenJDK, but is needed for a custom override in proprietary code. > > The change in Docs.gmk removes unnecessary extra loops so that SetupProcessMarkdown is called only once per module. This is necessary for the override mechanism to kick in for each module src set. > > The logic in ProcessMarkdown.gmk is more or less copied from SetupNativeCompilation. This pull request has now been integrated. Changeset: 588e314e Author: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/588e314e4b96f2a48d46ab8a088a7b8d26be318d Stats: 75 lines in 2 files changed: 14 ins; 11 del; 50 mod 8331886: Allow markdown src file overrides Reviewed-by: ihse ------------- PR: https://git.openjdk.org/jdk/pull/19132 From vpetko at openjdk.org Wed May 8 22:38:56 2024 From: vpetko at openjdk.org (Vladimir Petko) Date: Wed, 8 May 2024 22:38:56 GMT Subject: Integrated: 8331541: [i386] linking with libjvm.so fails after JDK-8283326 In-Reply-To: References: Message-ID: On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote: > Hi, > > The `.type _SafeFetch32_impl, at function` symbol declaration contains a spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that allows linking with undefined symbols > because having the flag on might cause bugs like this one or https://bugs.openjdk.org/browse/JDK-8329983 as the build succeeds even if some symbols are not defined. > Openjdk builds successfully without it on amd64, i386, armhf, arm64, s390, ppc64el and riscv64 with this change[1]. riscv64 build was done locally inside vm: > > Finished building target 'images' in configuration 'linux-riscv64-server-release' > ubuntu at ubuntu:~/jdk$ > > Unfortunately I do not know why it was introduced, so I might be missing something. > I am happy to drop it from this one or move it to a separate issue/pr. > > [1] https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+sourcepub/16076564/+listing-archive-extra This pull request has now been integrated. Changeset: 2d622152 Author: Vladimir Petko Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/2d622152b07bba0aba8fd5b1e24293e28d6e69f5 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod 8331541: [i386] linking with libjvm.so fails after JDK-8283326 Reviewed-by: djelinski, ihse ------------- PR: https://git.openjdk.org/jdk/pull/19048 From ihse at openjdk.org Wed May 8 22:40:12 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 May 2024 22:40:12 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v26] In-Reply-To: References:

Message-ID: <7GEk4PVZYWDSKt8bWCVSHD4f8zFmmJNWwJojxrFgwC4=.10d95786-32d8-40e8-bb21-1647da3ee39c@github.com> On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized). >> >> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime. >> >> Basic usage example: >> >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) >> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) >> $ ls ../linux-x86_64-server-release/images/jdk/jmods >> java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod >> java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod >> java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod >> java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.i... > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits: > > - Generate the runtime image link diff at jlink time > > But only do that once the plugin-pipeline has run. The generation is > enabled with the hidden option '--generate-linkable-runtime' and > the resource pools available at jlink time are being used to generate > the diff. > - Merge branch 'master' into jdk-8311302-jmodless-link > - Use shorter name for the build tool > - Review feedback from Erik J. > - Remove dependency on CDS which isn't needed anymore > - Fix coment > - Fix comment > - Fix typo > - Revert some now unneded build changes > - Follow build tools naming convention > - ... and 95 more: https://git.openjdk.org/jdk/compare/23a72a1f...67aea4ca make/Images.gmk line 100: > 98: > 99: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true) > 100: JLINK_JDK_EXTRA_OPTS := $(JLINK_JDK_EXTRA_OPTS) --generate-linkable-runtime I just noticed this slight improvement: Suggestion: JLINK_JDK_EXTRA_OPTS += --generate-linkable-runtime ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1594774220 From duke at openjdk.org Thu May 9 01:12:17 2024 From: duke at openjdk.org (xiaotaonan) Date: Thu, 9 May 2024 01:12:17 GMT Subject: RFR: 8331952: --enable-compatible-cds-alignment should be enabled by default Message-ID: --enable-compatible-cds-alignment should be enabled by default ------------- Commit messages: - --enable-compatible-cds-alignment should be enabled by default Changes: https://git.openjdk.org/jdk/pull/19150/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19150&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331952 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19150.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19150/head:pull/19150 PR: https://git.openjdk.org/jdk/pull/19150 From duke at openjdk.org Thu May 9 04:02:07 2024 From: duke at openjdk.org (duke) Date: Thu, 9 May 2024 04:02:07 GMT Subject: Withdrawn: 8311846: Resolve duplicate 'Thread' related symbols with JDK static linking In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou wrote: > Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach. > > Contributed by Chuck Rasbold and @jianglizhou. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17456 From stuefe at openjdk.org Thu May 9 05:07:56 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 9 May 2024 05:07:56 GMT Subject: RFR: 8331942: On Linux aarch64, CDS archives should be using 64K alignment by default In-Reply-To: <4-4Y0kUGd0M1mvIy16XdBFWZfmnu1AlC8ufi5aoNT6c=.d262020d-00ea-4093-9fc6-5b2d726ca676@github.com> References: <4-4Y0kUGd0M1mvIy16XdBFWZfmnu1AlC8ufi5aoNT6c=.d262020d-00ea-4093-9fc6-5b2d726ca676@github.com> Message-ID: On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote: > On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K, and (when run on Mac M1 hardware) 16K. > > Since forgetting to specify `--enable-compatible-cds-alignment` is a common error that is only noticed when running the produced JVM on hardware with different page size, we propose to enable that option by default on Linux aarch64. The cost is a moderate increase in CDS archive size (about 300K). > > I tested this patch on: > - x64 Linux > - x64 Linux, crossbuilding to aarch64 > - building natively on aarch64 Linux Does anyone else have an opinion on this matter? The question is: "Should we enable cds-compatible alignment in the configure options by default generally, not only for Linux aarch64" ? This would, in addition to the proposed change affecting Linux on aarch64, also affect MacOS x64. JVMs built there would be able to run, by default, in Rosetta. At the price of sligthly increased archive size of a dozen KB or so. If nobody objects, I will do that since I like the simplicity of it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19142#issuecomment-2101941697 From jwaters at openjdk.org Thu May 9 07:50:00 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 9 May 2024 07:50:00 GMT Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v2] In-Reply-To: References: Message-ID: > WIP > > This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Add check for compiler in configure - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis ------------- Changes: https://git.openjdk.org/jdk/pull/18915/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=01 Stats: 334 lines in 19 files changed: 154 ins; 25 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/18915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915 PR: https://git.openjdk.org/jdk/pull/18915 From jwaters at openjdk.org Thu May 9 07:50:01 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 9 May 2024 07:50:01 GMT Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis In-Reply-To: References: