From 841057341 at qq.com Sun May 1 13:15:25 2022 From: 841057341 at qq.com (=?utf-8?B?WmVsb25nIEdvbmc=?=) Date: Sun, 1 May 2022 21:15:25 +0800 Subject: Error when building openjdk-7 on Ubuntu 16.04 Message-ID: zelong at zelong-ThinkPad-T430:/home/sdb/jdk7u-jdk$ make all STATS: LIBRARY=verify, PRODUCT=java, OPTIMIZATION_LEVEL=HIGHER Rebuilding ../../../build/linux-amd64/lib/amd64/libverify.so because of ../../../build/linux-amd64/tmp/java/verify/obj64/.files_compiled mapfile-vers /usr/bin/gcc  -g -O2   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused -Wno-parentheses -pipe -fno-omit-frame-pointer -D_LITTLE_ENDIAN   -DNDEBUG -DARCH='"amd64"' -Damd64 -DLINUX -DRELEASE='"1.7.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -D_LP64=1 -I. -I../../../build/linux-amd64/tmp/java/verify/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export    -Xlinker -O1 -Xlinker -version-script=mapfile-vers  -Wl,--hash-style=both -Xlinker -z -Xlinker origin  -Xlinker -rpath -Xlinker \$ORIGIN  -Xlinker -z -Xlinker defs -L../../../build/linux-amd64/lib/amd64 -Wl,-soname=libverify.so   -shared -mimpure-text -o ../../../build/linux-amd64/lib/amd64/libverify.so    ../../../build/linux-amd64/tmp/java/verify/obj64/check_code.o    ../../../build/linux-amd64/tmp/java/verify/obj64/check_format.o   -L../../../build/linux-amd64/lib/amd64/server -ljvm  -lc gcc: error: unrecognized command line option '-mimpure-text' make[2]: *** [../../common/Library.gmk:255: ../../../build/linux-amd64/lib/amd64/libverify.so] Error 1 make[2]: Leaving directory '/home/sdb/jdk7u-jdk/make/java/verify' make[1]: *** [Makefile:67: all] Error 1 make[1]: Leaving directory '/home/sdb/jdk7u-jdk/make/java' make: *** [Makefile:250: all] Error 1 It seems that -mimpure-text is supported only Solaris operating system. The gcc preinstalled on Ubuntu 16.04 is: zelong at zelong-ThinkPad-T430:/home/sdb/jdk7u-jdk$ gcc --version gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Anyone knows how to fix the build error and build openjdk7 successfully? Or is there a valid ppa for me to install openjdk7 on my Ubuntu 16.04? From jpai at openjdk.java.net Mon May 2 06:25:28 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 2 May 2022 06:25:28 GMT Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts file [v2] In-Reply-To: References: Message-ID: <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com> > Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915? > > With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail. > > Testing done (on macOS): > > > cd test/failure_handler > make test > > Then verified that the generated environment.html had the `/etc/hosts` file content Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: print contents of hosts file in windows failure handler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8466/files - new: https://git.openjdk.java.net/jdk/pull/8466/files/673fd0bd..8591d0c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8466&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8466&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8466/head:pull/8466 PR: https://git.openjdk.java.net/jdk/pull/8466 From jpai at openjdk.java.net Mon May 2 06:25:33 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 2 May 2022 06:25:33 GMT Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts file In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915? > > With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail. > > Testing done (on macOS): > > > cd test/failure_handler > make test > > Then verified that the generated environment.html had the `/etc/hosts` file content Hello Erik, I've updated the PR to include capturing the contents of hosts file even on Windows. I've tested this against an internal Windows system where it correct shows the content: ---------------------------------------- [2022-05-02 06:08:52] [C:\cygwin\bin\bash.exe, -c, cat $WINDIR/System32/drivers/etc/hosts] timeout=20000 ---------------------------------------- # .... # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost ---------------------------------------- [2022-05-02 06:08:52] exit code: 0 time: 57 ms ---------------------------------------- ------------- PR: https://git.openjdk.java.net/jdk/pull/8466 From erikj at openjdk.java.net Mon May 2 12:59:34 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 2 May 2022 12:59:34 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic In-Reply-To: References: Message-ID: <4f0ydw14l2tRG_WpIjm0c4DXkgRKx0vCXBY7Bmzd6QU=.d6c49889-3754-41ed-ad0f-dc3ef201a6af@github.com> On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. Change to compare.sh looks good. Thanks for fixing this! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8478 From erikj at openjdk.java.net Mon May 2 13:03:58 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 2 May 2022 13:03:58 GMT Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts file [v2] In-Reply-To: <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com> References: <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com> Message-ID: On Mon, 2 May 2022 06:25:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915? >> >> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail. >> >> Testing done (on macOS): >> >> >> cd test/failure_handler >> make test >> >> Then verified that the generated environment.html had the `/etc/hosts` file content > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > print contents of hosts file in windows failure handler Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8466 From ihse at openjdk.java.net Mon May 2 14:03:51 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 2 May 2022 14:03:51 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. Marked as reviewed by ihse (Reviewer). Looks good to me. But you need hotspot reviewers as well. And thanks for fixing this! I think this is the last major known non-reproducibility bug in the JDK! ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8478 From ccheung at openjdk.java.net Mon May 2 21:05:29 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 2 May 2022 21:05:29 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. LGTM ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8478 From iklam at openjdk.java.net Tue May 3 00:46:04 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 May 2022 00:46:04 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic [v2] In-Reply-To: References: Message-ID: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into 8282828-uncompressed-oop-cds-archive-not-determinisic - 8282828: CDS uncompressed oops archive is not deterministic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8478/files - new: https://git.openjdk.java.net/jdk/pull/8478/files/f0261c51..8ddea12f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8478&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8478&range=00-01 Stats: 15990 lines in 519 files changed: 10708 ins; 2732 del; 2550 mod Patch: https://git.openjdk.java.net/jdk/pull/8478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8478/head:pull/8478 PR: https://git.openjdk.java.net/jdk/pull/8478 From vitaly.provodin at jetbrains.com Tue May 3 00:56:19 2022 From: vitaly.provodin at jetbrains.com (Vitaly Provodin) Date: Tue, 3 May 2022 07:56:19 +0700 Subject: zlib before 1.2.12 allows memory corruption (CVE-2018-25032) In-Reply-To: References: <8EA8A007-5C47-46CF-B126-6C57DCDAB281@jetbrains.com> Message-ID: Volker, Bernd, thanks for the replies - they were really useful Vitaly > On 27 Apr 2022, at 14:59, Volker Simonis wrote: > > Hi Bernd, Vitaly, > > Amazon Corretto [1] also includes the fixes for CVE-2018-25032. This > is our statement: > > "Based upon our analysis, OpenJDK/Corretto is not affected by > CVE-2018-25032, because the zlib "memLevel" parameter is not settable > and is fixed at 8, and the usage of the Z_FIXED strategy is prevented. > With these settings there is no way to invoke the issue described in > the CVE and we only include this fix out of an abundance of caution." > > You're right that the vulnerability can also be exploited without the > Z_FIXED strategy, but in that case only with memLevel set to "1" (see > [2] for more details). > > Given all the currently available information, I don't think there's a > reason to worry because of CVE-2018-25032 in the context of Java. > > Best regards, > Volker > > [1] https://github.com/corretto/corretto-8/blob/release-8.332.08.1/CHANGELOG.md > [2] https://www.openwall.com/lists/oss-security/2022/03/28/1 > > On Wed, Apr 27, 2022 at 1:21 AM Bernd Eckenfels wrote: >> >> Hello Vitaly, >> >> (Personal answer not affiliated with OpenJDK members) >> >> I had also asked about this before, but there was no answer (which is however not surprising, since it is the policy of OpenJDK and Oracle to not comment on unfixed security issues). >> >> My hope was, that by reporting it before the April update, the (trivial?) zlib update would be merged, but it is still the old version according to the source files. So it depends on build parameters and exploitability of the weakness if you are still in danger (I guess:). >> >> BTW while I can understand to not publish unfixed problems, it does really not do the java users a favor to not comment on generally known/published problems, especially not for 2 quarters. >> >> There is however a ray of light on the horizon, I see CVE-2018-25032 fixed in the Azul April Release Notes and asume they provide the update out of band. (Probably only for Windows binaries, haven?t analysed them yet) >> >> They state: >>> Our analysis shows that Azul Zulu and OpenJDK are not affected by CVE-2018-25032. >>> In OpenJDK, the Zlib "memLevel" parameter is always set to 8 and can not be changed by a >>> Java code, and the Z_FIXED strategy is permanently disabled. The CVE does not apply to Azul >>> Zulu and OpenJDK with these settings. However, Azul decided to include the corresponding >>> patch to the Zlib library in Azul products just in case someone chooses to use Zlib from Azul >>> Zulu outside of Java applications. >> >> (I am not sure of the analysis is complete I think the z_fixed was not a strict requirement, but I could be wrong.) >> >> Hopefully the vulnerability group will share their finding in a few month. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ________________________________ >> Von: security-dev im Auftrag von Vitaly Provodin >> Gesendet: Thursday, April 21, 2022 2:06:57 AM >> An: security-dev at openjdk.java.net ; build-dev at openjdk.java.net >> Cc: Vitaly Provodin >> Betreff: zlib before 1.2.12 allows memory corruption (CVE-2018-25032) >> >> Hi all, >> >> Recently we (at JetBrains) were faced with the vulnerability issue CVE-2018-25032 (zlib before 1.2.12 allows memory corruption?) >> It is known that Linux, macOS builds uses system?s zlib but Windows - bundled one (by default). >> On Linux and macOS users can work around the issue by installing proper zlib on their systems. >> Are there any ideas for Windows? - the way building (under Cygwin!) with system zlib looks unworkable in case if Cygwin is not installed on user's machines. >> >> It looks like after implementing https://bugs.openjdk.java.net/browse/JDK-8249963 (which also discussed here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067868.html) the resolution of such issues can be shifted to users but what can be done now? >> >> Thanks, >> Vitaly From jpai at openjdk.java.net Tue May 3 01:26:23 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 3 May 2022 01:26:23 GMT Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts file [v2] In-Reply-To: <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com> References: <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com> Message-ID: On Mon, 2 May 2022 06:25:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915? >> >> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail. >> >> Testing done (on macOS): >> >> >> cd test/failure_handler >> make test >> >> Then verified that the generated environment.html had the `/etc/hosts` file content > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > print contents of hosts file in windows failure handler Thank you Erik and Daniel for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8466 From jpai at openjdk.java.net Tue May 3 01:26:24 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 3 May 2022 01:26:24 GMT Subject: Integrated: 8285915: failure_handler: gather the contents of /etc/hosts file In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915? > > With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail. > > Testing done (on macOS): > > > cd test/failure_handler > make test > > Then verified that the generated environment.html had the `/etc/hosts` file content This pull request has now been integrated. Changeset: 45ca81ff Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/45ca81ff5f25ce7927c5debc2f89b41246b91b92 Stats: 13 lines in 3 files changed: 10 ins; 0 del; 3 mod 8285915: failure_handler: gather the contents of /etc/hosts file Reviewed-by: dfuchs, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8466 From iklam at openjdk.java.net Tue May 3 04:09:22 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 May 2022 04:09:22 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic [v2] In-Reply-To: <4f0ydw14l2tRG_WpIjm0c4DXkgRKx0vCXBY7Bmzd6QU=.d6c49889-3754-41ed-ad0f-dc3ef201a6af@github.com> References: <4f0ydw14l2tRG_WpIjm0c4DXkgRKx0vCXBY7Bmzd6QU=.d6c49889-3754-41ed-ad0f-dc3ef201a6af@github.com> Message-ID: <542amXyYwrXbb1TtpJL7sF_VfCmOYGdnyb_LFVrvqxM=.1eca9740-0401-4155-82ee-76fd9f8e53b9@github.com> On Mon, 2 May 2022 12:56:36 GMT, Erik Joelsson wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8282828-uncompressed-oop-cds-archive-not-determinisic >> - 8282828: CDS uncompressed oops archive is not deterministic > > Change to compare.sh looks good. Thanks for fixing this! Thanks @erikj79 @magicus @calvinccheung for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8478 From iklam at openjdk.java.net Tue May 3 04:09:23 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 May 2022 04:09:23 GMT Subject: Integrated: 8282828: CDS uncompressed oops archive is not deterministic In-Reply-To: References: Message-ID: <0Spq30mjW42FwZPLfIst0doH_37DxrjuiRAMqIBncgM=.ab9496dd-6e84-4990-9cc6-61b911f46352@github.com> On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. This pull request has now been integrated. Changeset: 64b5b2b0 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/64b5b2b0b3e5156d9b0c5f378ce3a1ae52aa0819 Stats: 86 lines in 6 files changed: 62 ins; 2 del; 22 mod 8282828: CDS uncompressed oops archive is not deterministic Reviewed-by: erikj, ihse, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/8478 From mbaesken at openjdk.java.net Tue May 3 07:04:56 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 07:04:56 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v2] In-Reply-To: References: Message-ID: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: set _WIN32_WINNT=0x0601 centrally in flags-cflags.m4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/aef2486f..dff223c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 3 07:10:58 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 07:10:58 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Copyright year in wepoll.c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/dff223c5..23b63c5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From alanb at openjdk.java.net Tue May 3 08:27:22 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 3 May 2022 08:27:22 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> On Thu, 28 Apr 2022 07:13:24 GMT, Matthias Baesken wrote: >> src/java.base/windows/native/libnio/ch/wepoll.c line 159: >> >>> 157: >>> 158: #undef _WIN32_WINNT >>> 159: #define _WIN32_WINNT 0x0601 >> >> This is 3rd party code and would prefer not change it if possible. > > Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I missed that wepoll.c is 3rd party code as well). I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mcimadamore at openjdk.java.net Tue May 3 10:09:36 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:09:36 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v36] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/d1fcf012..dc309e8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=35 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=34-35 Stats: 159 lines in 14 files changed: 96 ins; 8 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue May 3 10:09:38 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:09:38 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v35] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 08:15:32 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak Addressable javadoc We've tweaked the support for looking up symbols in the standard libraries - `CLinker` used to implement `SymbolLookup`, now `CLinker` returns a "default lookup" instead. We've also greatly improved the javadoc of `SymbolLookup` - many thanks to Alex for the help! New javadoc here: http://cr.openjdk.java.net/~mcimadamore/8282191/v3/javadoc/java.base/module-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue May 3 10:40:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:40:02 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - Tweak Addressable javadoc - Downcall and upcall tests use wrong layout which is missing some trailing padding - Simplify libraryLookup impl - Address CSR comments - Merge branch 'master' into foreign-preview - Add ValueLayout changes - Tweak support for array element var handle - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36 Stats: 65464 lines in 367 files changed: 43470 ins; 19432 del; 2562 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From erikj at openjdk.java.net Tue May 3 13:17:21 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 13:17:21 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c If we define this centrally using compiler flags, then we should not also update each location in the source. Those need to either be removed or left alone. In the cases where the source definition is guarded with an ifndef and there is a comment explaining why a particular version of windows is required, keeping it around could make sense. But on the other hand, since those defines are overridden using flags, they are likely to bit rot over time so we might as well just remove all of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From dholmes at openjdk.java.net Tue May 3 13:31:12 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 13:31:12 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected? I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ... and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 3 14:00:21 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 14:00:21 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> References: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> Message-ID: <09w3bQ6aE-0lywGwhamYkRZeizTLHpYID7C5dzyuzTc=.44290269-9308-4969-ac52-2f0423883b2b@github.com> On Tue, 3 May 2022 08:23:52 GMT, Alan Bateman wrote: >> Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I missed that wepoll.c is 3rd party code as well). > > I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now. Yes sure I did it . ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ysuenaga at openjdk.java.net Wed May 4 03:15:48 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 4 May 2022 03:15:48 GMT Subject: RFR: 8286105: SourceRevision.gmk should respect GIT variable Message-ID: We can specify `git` binary via `GIT` in configure script, but it does not affect in SourceRevision.gmk . ------------- Commit messages: - 8286105: SourceRevision.gmk should respect GIT variable Changes: https://git.openjdk.java.net/jdk/pull/8526/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8526&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286105 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8526/head:pull/8526 PR: https://git.openjdk.java.net/jdk/pull/8526 From mbaesken at openjdk.java.net Wed May 4 07:37:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 07:37:14 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c Interesting fact : we run now into this compile error : d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1262): error C2065: 'NCRYPT_CIPHER_KEY_BLOB': undeclared identifier d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1280): error C2065: 'NCRYPT_PROTECTED_KEY_BLOB': undeclared identifier Reason seems that already for some time ( at least OpenJDK 11 (!) ) we have an implicit minimum requirement of Windows 8 / Windows 2012 APIs for this code, so enforcing Win 7 is too old : https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptexportkey NCRYPT_PROTECTED_KEY_BLOB Export a protected key in a NCRYPT_KEY_BLOB_HEADER structure. Windows 8 and Windows Server 2012: Support for this value begins. NCRYPT_CIPHER_KEY_BLOB Export a cipher key in a NCRYPT_KEY_BLOB_HEADER structure. Windows 8 and Windows Server 2012: Support for this value begins. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 07:42:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 07:42:14 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: <9KE3CEXRqW4z5bQgy9E5ydrFvcxY4LgV9zA-KGRH09M=.e21bbecb-5e37-4887-9a74-7e4227c70c07@github.com> On Tue, 3 May 2022 13:27:41 GMT, David Holmes wrote: > I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected? > > I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ... > > and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ? Hi David, I agree the other locations as long as they are not 3rd party code should be cleaned up. Someone using an API that is only available in later Windows versions would get a redefinition warning as long as no undefine is done. But we have to set _WIN32_WINNT anyway to a higher value (windows8, I think that's 0x0602) to compile src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp . ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 08:00:08 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 08:00:08 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: Message-ID: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust API level to Windows 8 for security.cpp and do some cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/23b63c5b..721528c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=02-03 Stats: 31 lines in 7 files changed: 1 ins; 26 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From dholmes at openjdk.java.net Wed May 4 08:38:24 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 08:38:24 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 09:11:17 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 09:11:17 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:34:43 GMT, David Holmes wrote: > I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? I found this info here https://stackoverflow.com/questions/37668692/visual-studio-setting-winver-win32-winnt-to-windows-8-on-windows-7 "VS 2012 uses the Windows 8.0 SDK which defaults to _WIN32_WINNT=0x0602 (Windows 8). VS 2013 / 2015 uses the Windows 8.1 SDK which defaults to _WIN32_WINNT=0x0603 (Windows 8.1). If you use VS 2015 and the Windows 10 SDK, it defaults to _WIN32_WINNT=0x0A00 (Windows 10)." So it seems you get some more or less recent default when working with a not too old compiler/SDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From sgehwolf at openjdk.java.net Wed May 4 09:25:25 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 4 May 2022 09:25:25 GMT Subject: RFR: 8286105: SourceRevision.gmk should respect GIT variable In-Reply-To: References: Message-ID: On Wed, 4 May 2022 03:06:44 GMT, Yasumasa Suenaga wrote: > We can specify `git` binary via `GIT` in configure script, but it does not affect in SourceRevision.gmk . LGTM ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8526 From erikj at openjdk.java.net Wed May 4 12:50:22 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 4 May 2022 12:50:22 GMT Subject: RFR: 8286105: SourceRevision.gmk should respect GIT variable In-Reply-To: References: Message-ID: On Wed, 4 May 2022 03:06:44 GMT, Yasumasa Suenaga wrote: > We can specify `git` binary via `GIT` in configure script, but it does not affect in SourceRevision.gmk . Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8526 From duke at openjdk.java.net Wed May 4 16:56:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 4 May 2022 16:56:40 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 10:40:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: > > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Tweak support for Linker lookup > Improve javadoc of SymbolLookup > - Tweak Addressable javadoc > - Downcall and upcall tests use wrong layout which is missing some trailing padding > - Simplify libraryLookup impl > - Address CSR comments > - Merge branch 'master' into foreign-preview > - Add ValueLayout changes > - Tweak support for array element var handle > - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 116: > 114: * Linker nativeLinker = Linker.nativeLinker(); > 115: * SymbolLookup stdlib = nativeLinker.defaultLookup(); > 116: * MemorySegment malloc = stdlib.lookup("malloc"); This?should?be: Suggestion: * Optional malloc = stdlib.lookup("malloc"); or Suggestion: * MemorySegment malloc = stdlib.lookup("malloc").orElseThrow(); src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: > 151: static SymbolLookup loaderLookup() { > 152: Class caller = Reflection.getCallerClass(); > 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:24:29 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:24:29 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:47:28 GMT, ExE Boss wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Tweak support for Linker lookup >> Improve javadoc of SymbolLookup >> - Tweak Addressable javadoc >> - Downcall and upcall tests use wrong layout which is missing some trailing padding >> - Simplify libraryLookup impl >> - Address CSR comments >> - Merge branch 'master' into foreign-preview >> - Add ValueLayout changes >> - Tweak support for array element var handle >> - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab > > src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: > >> 151: static SymbolLookup loaderLookup() { >> 152: Class caller = Reflection.getCallerClass(); >> 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); > > Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? > > [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. > [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:30:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:30:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v38] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak examples in SymbolLookup javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/41d055ab..853f06b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36-37 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:32:49 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:32:49 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:20:21 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: >> >>> 151: static SymbolLookup loaderLookup() { >>> 152: Class caller = Reflection.getCallerClass(); >>> 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); >> >> Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? >> >> [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. >> [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. > > Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? > > As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:47:30 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:47:30 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:29:53 GMT, Maurizio Cimadamore wrote: >> Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? >> >> As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). > > Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From ysuenaga at openjdk.java.net Thu May 5 00:31:24 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 5 May 2022 00:31:24 GMT Subject: Integrated: 8286105: SourceRevision.gmk should respect GIT variable In-Reply-To: References: Message-ID: <8_R-VxpFxd3aHUhgu27FY9kvkJOMNmvZDggpvCJ8VdQ=.a1f10129-ff94-4582-ac41-a50ec12ec57a@github.com> On Wed, 4 May 2022 03:06:44 GMT, Yasumasa Suenaga wrote: > We can specify `git` binary via `GIT` in configure script, but it does not affect in SourceRevision.gmk . This pull request has now been integrated. Changeset: d43ae723 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/d43ae723b869e13d30f4ca0cf3d41349bc29bdc7 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8286105: SourceRevision.gmk should respect GIT variable Reviewed-by: sgehwolf, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8526 From sundar at openjdk.java.net Thu May 5 09:08:39 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 5 May 2022 09:08:39 GMT Subject: RFR: 8282060: RemoteRuntimeImageTest is not actually testing on JDK 8 Message-ID: This test requires jdk8 to be available while running jdk tests. But JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test. The test vacuously passes just printing a message. There are already tests that exercise jrt-fs.jar on the same JDK being tested and so basic jrt-fs.jar is covered for same target JDK case. ------------- Commit messages: - 8282060: RemoteRuntimeImageTest is not actually testing on JDK 8 Changes: https://git.openjdk.java.net/jdk/pull/8547/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8547&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282060 Stats: 202 lines in 3 files changed: 0 ins; 202 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8547.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8547/head:pull/8547 PR: https://git.openjdk.java.net/jdk/pull/8547 From alanb at openjdk.java.net Thu May 5 09:55:13 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 May 2022 09:55:13 GMT Subject: RFR: 8282060: RemoteRuntimeImageTest is not actually testing on JDK 8 In-Reply-To: References: Message-ID: On Thu, 5 May 2022 09:00:47 GMT, Athijegannathan Sundararajan wrote: > This test requires jdk8 to be available while running jdk tests. But JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test. The test vacuously passes just printing a message. There are already tests that exercise jrt-fs.jar on the same JDK being tested and so basic jrt-fs.jar is covered for same target JDK case. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8547 From erikj at openjdk.java.net Thu May 5 12:48:17 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 5 May 2022 12:48:17 GMT Subject: RFR: 8282060: RemoteRuntimeImageTest is not actually testing on JDK 8 In-Reply-To: References: Message-ID: On Thu, 5 May 2022 09:00:47 GMT, Athijegannathan Sundararajan wrote: > This test requires jdk8 to be available while running jdk tests. But JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test. The test vacuously passes just printing a message. There are already tests that exercise jrt-fs.jar on the same JDK being tested and so basic jrt-fs.jar is covered for same target JDK case. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8547 From sundar at openjdk.java.net Thu May 5 13:26:31 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 5 May 2022 13:26:31 GMT Subject: Integrated: 8282060: RemoteRuntimeImageTest is not actually testing on JDK 8 In-Reply-To: References: Message-ID: On Thu, 5 May 2022 09:00:47 GMT, Athijegannathan Sundararajan wrote: > This test requires jdk8 to be available while running jdk tests. But JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test. The test vacuously passes just printing a message. There are already tests that exercise jrt-fs.jar on the same JDK being tested and so basic jrt-fs.jar is covered for same target JDK case. This pull request has now been integrated. Changeset: ede06c3c Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/jdk/commit/ede06c3c5f74c64dac3889d35b02541897ba4d94 Stats: 202 lines in 3 files changed: 0 ins; 202 del; 0 mod 8282060: RemoteRuntimeImageTest is not actually testing on JDK 8 Reviewed-by: alanb, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8547 From mchung at openjdk.java.net Thu May 5 16:26:37 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 16:26:37 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:44:08 GMT, Maurizio Cimadamore wrote: >> Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. > > Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Thu May 5 16:42:25 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 16:42:25 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:22:41 GMT, Mandy Chung wrote: >> Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. > > `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). > > To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`. I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader. This is consistent with JNI `FindClass` when invoked with no caller frame. It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class. However, the existing behavior may likely be unchanged because of the compatibility risk. [1] https://bugs.openjdk.java.net/browse/JDK-8281001 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From asemenyuk at openjdk.java.net Thu May 5 19:47:51 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 5 May 2022 19:47:51 GMT Subject: RFR: 8284675: "jpackage.exe" creates application launcher without Windows Application Manfiest Message-ID: <5zWKNkTC_8RO7mPU-llgHfCJpyLHl6ngCVatc_wGSIo=.e976c589-1c56-49f0-9b2b-75672e082ff8@github.com> Copy missing manifest-related parameters to `SetupJdkExecutable` calls building app launchers from `SetupBuildLauncher` function:https://github.com/openjdk/jdk/blob/0c3094c8186b4d53e8bad80e2369fc7b9ae9e201/make/common/modules/LauncherCommon.gmk#L174-L175 ------------- Commit messages: - 8284675: "jpackage.exe" creates application launcher without Windows Application Manfiest Changes: https://git.openjdk.java.net/jdk/pull/8561/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8561&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284675 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8561.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8561/head:pull/8561 PR: https://git.openjdk.java.net/jdk/pull/8561 From erikj at openjdk.java.net Thu May 5 20:26:50 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 5 May 2022 20:26:50 GMT Subject: RFR: 8284675: "jpackage.exe" creates application launcher without Windows Application Manfiest In-Reply-To: <5zWKNkTC_8RO7mPU-llgHfCJpyLHl6ngCVatc_wGSIo=.e976c589-1c56-49f0-9b2b-75672e082ff8@github.com> References: <5zWKNkTC_8RO7mPU-llgHfCJpyLHl6ngCVatc_wGSIo=.e976c589-1c56-49f0-9b2b-75672e082ff8@github.com> Message-ID: On Thu, 5 May 2022 19:02:51 GMT, Alexey Semenyuk wrote: > Copy missing manifest-related parameters to `SetupJdkExecutable` calls building app launchers from `SetupBuildLauncher` function:https://github.com/openjdk/jdk/blob/0c3094c8186b4d53e8bad80e2369fc7b9ae9e201/make/common/modules/LauncherCommon.gmk#L174-L175 Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8561 From asemenyuk at openjdk.java.net Thu May 5 20:29:47 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 5 May 2022 20:29:47 GMT Subject: Integrated: 8284675: "jpackage.exe" creates application launcher without Windows Application Manfiest In-Reply-To: <5zWKNkTC_8RO7mPU-llgHfCJpyLHl6ngCVatc_wGSIo=.e976c589-1c56-49f0-9b2b-75672e082ff8@github.com> References: <5zWKNkTC_8RO7mPU-llgHfCJpyLHl6ngCVatc_wGSIo=.e976c589-1c56-49f0-9b2b-75672e082ff8@github.com> Message-ID: On Thu, 5 May 2022 19:02:51 GMT, Alexey Semenyuk wrote: > Copy missing manifest-related parameters to `SetupJdkExecutable` calls building app launchers from `SetupBuildLauncher` function:https://github.com/openjdk/jdk/blob/0c3094c8186b4d53e8bad80e2369fc7b9ae9e201/make/common/modules/LauncherCommon.gmk#L174-L175 This pull request has now been integrated. Changeset: e7adc283 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/e7adc283c60c6c8e7bb174b45a2cd68823a9e81e Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8284675: "jpackage.exe" creates application launcher without Windows Application Manfiest Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8561 From mcimadamore at openjdk.java.net Thu May 5 20:54:53 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 5 May 2022 20:54:53 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/853f06b8..4d24ffa9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37-38 Stats: 22 lines in 2 files changed: 16 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu May 5 20:54:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 5 May 2022 20:54:55 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: <-zAvw8aE9e94OWQyDLUT3IqPzKJFT3v0x_HQVJObonc=.3370a3b7-e797-439f-8a72-ff6d3ec59be4@github.com> On Thu, 5 May 2022 16:39:08 GMT, Mandy Chung wrote: >> `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). >> >> To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. > > When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`. I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader. This is consistent with JNI `FindClass` when invoked with no caller frame. > > It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class. However, the existing behavior may likely be unchanged because of the compatibility risk. > > [1] https://bugs.openjdk.java.net/browse/JDK-8281001 Thanks for the comments. I've pushed a new change which fixes a couple of thing: * first, for `SymbolLookup.loaderLookup`, the system class loader is used when no caller class exists (e.g. when method is called from JNI). If caller class exist but its loader is null (boot loader), we just call ClassLoader::findNative with a `null` loader which will do the right thing (thanks @mlchung for the tips!) * second, the restricted method check in `Reflection::ensureNativeAccess` has been improved to also work in case where caller class is `null`. In such cases, a dummy unnamed module module is used for the check. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Thu May 5 21:34:54 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 21:34:54 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 20:54:53 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI > * Tweak restricted method check to work when there's no caller class src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161: > 159: ClassLoader.getSystemClassLoader(); > 160: MemorySession loaderSession = (loader == null) ? > 161: MemorySession.global() : // boot loader never goes away The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded. Should they use the globel memory session? src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: > 118: // if there is no caller class, act as if the call came from an unnamed module > 119: Module module = currentClass != null ? > 120: currentClass.getModule() : Holder.FALLBACK_MODULE; This can be simplified to: Module module = currentClass != null ? currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); No need to have the Holder class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Fri May 6 01:57:56 2022 From: duke at openjdk.java.net (duke) Date: Fri, 6 May 2022 01:57:56 GMT Subject: Withdrawn: 8282944: GHA: Add Alpine Linux x86_64 pre-integration check In-Reply-To: References: Message-ID: <4LsHw68NY2lmsqSox_BShmc8NGarHCOW90wnjrkU_v8=.503d74c5-df13-4c0b-b722-88f1e6abdbf9@github.com> On Thu, 10 Mar 2022 09:57:17 GMT, George Adams wrote: > Adds Alpine build CI job to the GitHub actions submit.yml. I can add tests too if people think that would be useful but for now I've left it as just build. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7771 From mbaesken at openjdk.java.net Fri May 6 07:36:48 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 May 2022 07:36:48 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 09:08:28 GMT, Matthias Baesken wrote: > Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? Hi David , I did one more try with my current setup (VS2017 on a Win10 notebook). I did not set _WIN32_WINNT. My little test program #include #include int main() { #ifdef _WIN32_WINNT printf("_WIN32_WINNT is defined .\n"); #if (_WIN32_WINNT == 0x0600) printf("Vista API setting\n"); #endif #if (_WIN32_WINNT == 0x0601) printf("Win 7 API setting\n"); #endif #if (_WIN32_WINNT == 0x0602) printf("Win 8 API setting\n"); #endif #if (_WIN32_WINNT == 0x0603) printf("Win 8.1 API setting\n"); #endif #if (_WIN32_WINNT == 0x0A00) printf("Win 10 API setting\n"); #endif #endif return 0; } shows me _WIN32_WINNT is defined . Win 10 API setting So I think with our current compilers in use like VS2017 / VS2019 we allow Win10 APIs in most of our code except a few places where we set _WIN32_WINNT and go back to some mixture of older APIs. Not sure if this is a good thing, we could break for example Win 8.1/Win2012 compatibility easily this way. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mcimadamore at openjdk.java.net Fri May 6 08:44:18 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 08:44:18 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> On Thu, 5 May 2022 21:28:32 GMT, Mandy Chung wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class > > src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161: > >> 159: ClassLoader.getSystemClassLoader(); >> 160: MemorySession loaderSession = (loader == null) ? >> 161: MemorySession.global() : // boot loader never goes away > > The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded. Should they use the globel memory session? good idea > src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: > >> 118: // if there is no caller class, act as if the call came from an unnamed module >> 119: Module module = currentClass != null ? >> 120: currentClass.getModule() : Holder.FALLBACK_MODULE; > > This can be simplified to: > > Module module = currentClass != null ? > currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); > > > No need to have the Holder class. gah! I missed that :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From dholmes at openjdk.java.net Fri May 6 09:52:47 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 09:52:47 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup This seems okay to me in this form. I agree that explicitly setting this is better than unknowingly using API's that might not be available on supported platforms. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Fri May 6 09:57:47 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 May 2022 09:57:47 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Hi David, thanks for the review ! ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mcimadamore at openjdk.java.net Fri May 6 11:51:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 11:51:46 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v40] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add tests for loaderLookup/restricted method corner cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/4d24ffa9..b71c4e93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38-39 Stats: 248 lines in 10 files changed: 239 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 6 11:51:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 11:51:46 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> References: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> Message-ID: On Fri, 6 May 2022 08:42:12 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: >> >>> 118: // if there is no caller class, act as if the call came from an unnamed module >>> 119: Module module = currentClass != null ? >>> 120: currentClass.getModule() : Holder.FALLBACK_MODULE; >> >> This can be simplified to: >> >> Module module = currentClass != null ? >> currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); >> >> >> No need to have the Holder class. > > gah! I missed that :-) I've addressed these comments (thanks!) and also added some tests for these corner cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From erikj at openjdk.java.net Fri May 6 12:47:41 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 6 May 2022 12:47:41 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: <5t5qsNQ4XMMB_1ACFCDIKGj1BxBnsmAAq5d4C5z3yQU=.c1c2bb90-57dc-4754-a2cd-56b0e5d58843@github.com> On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ihse at openjdk.java.net Fri May 6 14:38:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 6 May 2022 14:38:50 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Looks good, thanks for doing this cleanup. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Fri May 6 16:00:59 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 6 May 2022 16:00:59 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v40] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 11:51:46 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add tests for loaderLookup/restricted method corner cases src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 116: > 114: // if there is no caller class, act as if the call came from unnamed module of system class loader > 115: Module module = currentClass != null ? > 116: currentClass.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); **Nit:** maybe?add a?line?break Suggestion: currentClass.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 6 16:48:11 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 16:48:11 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v41] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/b71c4e93..f823bf84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=40 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39-40 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Fri May 6 16:55:12 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 6 May 2022 16:55:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v41] In-Reply-To: References: Message-ID: <0liX9cVSEjplWxVgGoM5rN2JZLqN27jSsNxjbucze_o=.fbc3a8fa-acdf-45f4-a717-0fbaa13760d2@github.com> On Fri, 6 May 2022 16:48:11 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon May 9 08:26:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 08:26:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v42] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - Tweak Addressable javadoc - Downcall and upcall tests use wrong layout which is missing some trailing padding - ... and 52 more: https://git.openjdk.java.net/jdk/compare/39f4434f...3c88a2ef ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41 Stats: 65712 lines in 373 files changed: 43721 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From magnus.ihse.bursie at oracle.com Mon May 9 13:18:19 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 9 May 2022 15:18:19 +0200 Subject: Fwd: JDK 19+21 early-access build is reproducible In-Reply-To: References: Message-ID: <4d37770c-d822-7ed3-3e4e-afd3decaca9d@oracle.com> Just a FYI: The fix of the last remaining bug towards full reproducibility (on Linux, at least) of the JDK was given attention on the reproducible-builds mailing list. /Magnus -------- Forwarded Message -------- Subject: JDK 19+21 early-access build is reproducible Date: Fri, 6 May 2022 13:48:20 -0700 From: John Neffenger Reply-To: General discussions about reproducible builds Organization: Status Six Communications To: Reproducible Builds List Starting yesterday, for the first time, the JDK can create reproducible builds of the JDK! Pull request 8478 [1] was the last reproducibility bug remaining in my JDK builds on Linux, and it's included in the latest JDK 19+21 early-access build. [2] OpenJDK 19 will be generally available on September 20, 2022. That also means there's nothing in the JDK that's holding back any Java application from having reproducible builds. The link below lists all the "reproducible build" fixes for OpenJDK: https://bugs.openjdk.java.net/issues/?jql=labels+%3D+reproducible-build I tested on six Linux architectures (amd64, arm64, armhf, i386, ppc64el, s390x), and the entire JDK is reproducible including the command-line tools, demos, API documentation, JMOD archives, native libraries, and man pages -- even when using a different build path. Note that I didn't test on macOS or Windows. A big thank you to Magnus Ihse Bursie and Andrew Leonard for doing much of the work to make this possible. John [1]: https://github.com/openjdk/jdk/pull/8478 [2]: https://jdk.java.net/19/ From asotona at openjdk.java.net Mon May 9 16:05:46 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 9 May 2022 16:05:46 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments Message-ID: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. Thanks for your review, Adam ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments - 8244681: Add a warning for possibly lossy conversion in compound assignments Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244681 Stats: 449 lines in 26 files changed: 444 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From erikj at openjdk.java.net Mon May 9 16:33:56 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 9 May 2022 16:33:56 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8599 From mcimadamore at openjdk.java.net Mon May 9 17:41:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 17:41:10 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix crashes in heap segment benchmarks due to misaligned access ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/3c88a2ef..7b774297 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=42 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41-42 Stats: 41 lines in 2 files changed: 3 ins; 4 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From prr at openjdk.java.net Mon May 9 17:55:55 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 17:55:55 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Marked as reviewed by prr (Reviewer). test/langtools/tools/javac/lint/LossyConversions.java line 131: > 129: @SuppressWarnings("lossy-conversions") > 130: public void supressedLossyConversions() { > 131: byte a = 0; you might want to spell suppressed correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From prr at openjdk.java.net Mon May 9 18:06:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:06:54 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: <4TPEAEob1ukdLvqdnzddoOBEGrsVfkaQEG5-307Mxjw=.130e42ef-8170-4dcf-bce5-3b69615a6c2a@github.com> On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Mon May 9 18:17:00 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 9 May 2022 18:17:00 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 17:41:10 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix crashes in heap segment benchmarks due to misaligned access test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69: > 67: static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8); > 68: static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8); > 69: static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle(); To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`. -------------------------------------------------------------------------------- Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1] [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From sgehwolf at openjdk.java.net Mon May 9 18:46:11 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 9 May 2022 18:46:11 GMT Subject: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't Message-ID: `make test TEST="gtest: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <8O_QfMi1b_fhddBS7yzm9cwzf-l6nWbfNs6qFJWdtuU=.22f44b80-54e8-4249-8ece-d02be29f4267@github.com> On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam I see there is already a bug filed to address situations found by the new warning in the JDK's libraries (JDK-8286374). As a matter of policy, I recommend the (potential) warnings be addressed in at least the java.base and java.desktop modules before the new warning is enabled. In other words, a priority should be given to keeping java.base and java.desktop compiling successfully with all warnings enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From mcimadamore at openjdk.java.net Mon May 9 20:30:09 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 20:30:09 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:09:51 GMT, ExE Boss wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix crashes in heap segment benchmarks due to misaligned access > > test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69: > >> 67: static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8); >> 68: static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8); >> 69: static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle(); > > To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`. > > -------------------------------------------------------------------------------- > > Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1] > > [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43 I noted other possible cleanups for benchmarks, I'll work on something after we integrate this PR as I'd like to minimize the churn. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From erikj at openjdk.java.net Mon May 9 23:28:23 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 9 May 2022 23:28:23 GMT Subject: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45] Message-ID: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> The way LauncherCommon.gmk is currently written, it's only meant to be included from "make/module//Launcher.gmk", or at least only from one single place for each module. This is because the man page generation that happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, LauncherCommon.gmk is now called from two separate sub makefiles, both make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. These files are called from the top level targets jdk.jpackage-libs and jdk.jpackage-launchers respectively. These top level targets are assumed to be able to run independently of each other, which is normally fine, but now they define the same rules for the same files. This creates a race where one may be deleting files that the other one is creating, causing directories to disappear while files are being written to them. This can fail the build, but also risks silently corrupting the build. This patch fixes this by adding a conditional around the man page generation, which helps guarantee that man pages are only processed when called from make/module//Launcher.gmk. It's a bit of a hack, but it's building on top of the existing design of piggybacking man page generation on the launchers build. Also fixing broken whitespace further down in the file (tabs->space). ------------- Commit messages: - JDK-8286429 Changes: https://git.openjdk.java.net/jdk/pull/8618/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8618&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286429 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8618/head:pull/8618 PR: https://git.openjdk.java.net/jdk/pull/8618 From dholmes at openjdk.java.net Tue May 10 01:39:41 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 10 May 2022 01:39:41 GMT Subject: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45] In-Reply-To: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> References: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> Message-ID: On Mon, 9 May 2022 23:18:47 GMT, Erik Joelsson wrote: > The way LauncherCommon.gmk is currently written, it's only meant to be included from "make/module//Launcher.gmk", or at least only from one single place for each module. This is because the man page generation that happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, LauncherCommon.gmk is now called from two separate sub makefiles, both make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. These files are called from the top level targets jdk.jpackage-libs and jdk.jpackage-launchers respectively. These top level targets are assumed to be able to run independently of each other, which is normally fine, but now they define the same rules for the same files. This creates a race where one may be deleting files that the other one is creating, causing directories to disappear while files are being written to them. This can fail the build, but also risks silently corrupting the build. > > This patch fixes this by adding a conditional around the man page generation, which helps guarantee that man pages are only processed when called from make/module//Launcher.gmk. It's a bit of a hack, but it's building on top of the existing design of piggybacking man page generation on the launchers build. > > Also fixing broken whitespace further down in the file (tabs->space). I'm still unclear how `--disable-manpages` is supposed to affect this logic, as they seemed to be the failing configs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8618 From asemenyuk at openjdk.java.net Tue May 10 02:54:41 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 10 May 2022 02:54:41 GMT Subject: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45] In-Reply-To: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> References: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> Message-ID: On Mon, 9 May 2022 23:18:47 GMT, Erik Joelsson wrote: > The way LauncherCommon.gmk is currently written, it's only meant to be included from "make/module//Launcher.gmk", or at least only from one single place for each module. This is because the man page generation that happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, LauncherCommon.gmk is now called from two separate sub makefiles, both make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. These files are called from the top level targets jdk.jpackage-libs and jdk.jpackage-launchers respectively. These top level targets are assumed to be able to run independently of each other, which is normally fine, but now they define the same rules for the same files. This creates a race where one may be deleting files that the other one is creating, causing directories to disappear while files are being written to them. This can fail the build, but also risks silently corrupting the build. > > This patch fixes this by adding a conditional around the man page generation, which helps guarantee that man pages are only processed when called from make/module//Launcher.gmk. It's a bit of a hack, but it's building on top of the existing design of piggybacking man page generation on the launchers build. > > Also fixing broken whitespace further down in the file (tabs->space). Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8618 From alanb at openjdk.java.net Tue May 10 05:46:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 05:46:40 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 10 06:48:40 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 May 2022 06:48:40 GMT Subject: Integrated: JDK-8285730: unify _WIN32_WINNT settings In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). This pull request has now been integrated. Changeset: 4fd79a6a Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/4fd79a6ad2683e4863bd4e311cb01cbc30ebf57f Stats: 33 lines in 7 files changed: 2 ins; 25 del; 6 mod 8285730: unify _WIN32_WINNT settings Reviewed-by: dholmes, erikj, ihse, prr, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From matthias.baesken at sap.com Tue May 10 08:29:35 2022 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 10 May 2022 08:29:35 +0000 Subject: VS2017 build errors jdk/jdk Message-ID: Hello, it seems jdk/jdk does not build any more with VS2017. Should we still support this compiler ? For the error see : https://bugs.openjdk.java.net/browse/JDK-8286459 8286459: compile error with VS2017 in continuationFreezeThaw.cpp Thanks, Matthias From sgehwolf at openjdk.java.net Tue May 10 08:46:44 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 10 May 2022 08:46:44 GMT Subject: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't [v2] In-Reply-To: References: Message-ID: > `make test TEST="gtest: > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Handle both 'cases' and 'suites' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8605/files - new: https://git.openjdk.java.net/jdk/pull/8605/files/54f90f4e..97dccef9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8605&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8605&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8605.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8605/head:pull/8605 PR: https://git.openjdk.java.net/jdk/pull/8605 From asotona at openjdk.java.net Tue May 10 08:46:45 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Tue, 10 May 2022 08:46:45 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam I agree with the priority to keep java.base and java.desktop clean from possibly lossy conversions, so the related issues should probably raise from P4 priority level. However this lint warning as a part of the javac is critical to confirm that the situations have been correctly addressed. If we want to avoid "blind" patching, we only two possible scenarios: 1. big homogenous patch including hundreds of fixed lines of code across many "moving-target" classes, together with lint warning implemented and enabled 2. javac lint patch (disabled for affected JDK modules build) goes first, so each case can be resolved, reviewed and validated in individual patch >From complexity and cost perspective I prefer the second scenario. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From sgehwolf at openjdk.java.net Tue May 10 08:46:45 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 10 May 2022 08:46:45 GMT Subject: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:39:28 GMT, Severin Gehwolf wrote: > `make test TEST="gtest: > Thoughts? Apparently gtest 1.8.1 uses `cases`. I've updated the patch to handle both: `suites` and `cases`. If somebody could test it with gtest 1.8.1 I'd appreciate it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8605 From asotona at openjdk.java.net Tue May 10 09:07:44 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Tue, 10 May 2022 09:07:44 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v2] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/47779ba5..6b3942b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From Alan.Bateman at oracle.com Tue May 10 11:16:20 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 May 2022 12:16:20 +0100 Subject: VS2017 build errors jdk/jdk In-Reply-To: References: Message-ID: On 10/05/2022 09:29, Baesken, Matthias wrote: > Hello, it seems jdk/jdk does not build any more with VS2017. > Should we still support this compiler ? > > For the error see : > > https://bugs.openjdk.java.net/browse/JDK-8286459 > 8286459: compile error with VS2017 in continuationFreezeThaw.cpp > In Oracle, we moved from using VS2019 16.9.3 to VS2022 17.1.0 a few months ago. I checked the Microsoft site to get the status of VS2017. It says that the "Mainstream End Date" for that release was April 2022 so I guess it's not easy to get updates without extended support now. So maybe it time to look at it, it might be easier to have a smaller set of VS releases to support. -Alan From ihse at openjdk.java.net Tue May 10 11:18:48 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 10 May 2022 11:18:48 GMT Subject: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45] In-Reply-To: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> References: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> Message-ID: <-nCobXsGwS1du0lvpB7Xmnvlrjf3Xkifq4FRQHMjMjM=.e764b82d-666a-45c9-b55f-dd9ac60ce82e@github.com> On Mon, 9 May 2022 23:18:47 GMT, Erik Joelsson wrote: > The way LauncherCommon.gmk is currently written, it's only meant to be included from "make/module//Launcher.gmk", or at least only from one single place for each module. This is because the man page generation that happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, LauncherCommon.gmk is now called from two separate sub makefiles, both make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. These files are called from the top level targets jdk.jpackage-libs and jdk.jpackage-launchers respectively. These top level targets are assumed to be able to run independently of each other, which is normally fine, but now they define the same rules for the same files. This creates a race where one may be deleting files that the other one is creating, causing directories to disappear while files are being written to them. This can fail the build, but also risks silently corrupting the build. > > This patch fixes this by adding a conditional around the man page generation, which helps guarantee that man pages are only processed when called from make/module//Launcher.gmk. It's a bit of a hack, but it's building on top of the existing design of piggybacking man page generation on the launchers build. > > Also fixing broken whitespace further down in the file (tabs->space). Marked as reviewed by ihse (Reviewer). I think this looks good. I'm just curious why this started to show up now. There have been no changes in this area lately, have it? Is it just pure (bad) luck that the race did not happen before? ------------- PR: https://git.openjdk.java.net/jdk/pull/8618 From ihse at openjdk.java.net Tue May 10 11:18:48 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 10 May 2022 11:18:48 GMT Subject: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45] In-Reply-To: References: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> Message-ID: On Tue, 10 May 2022 01:36:06 GMT, David Holmes wrote: >> The way LauncherCommon.gmk is currently written, it's only meant to be included from "make/module//Launcher.gmk", or at least only from one single place for each module. This is because the man page generation that happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, LauncherCommon.gmk is now called from two separate sub makefiles, both make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. These files are called from the top level targets jdk.jpackage-libs and jdk.jpackage-launchers respectively. These top level targets are assumed to be able to run independently of each other, which is normally fine, but now they define the same rules for the same files. This creates a race where one may be deleting files that the other one is creating, causing directories to disappear while files are being written to them. This can fail the build, but also risks silently corrupting the build. >> >> This patch fixes this by adding a conditional around the man page generation, which helps guarantee that man pages are only processed when called from make/module//Launcher.gmk. It's a bit of a hack, but it's building on top of the existing design of piggybacking man page generation on the launchers build. >> >> Also fixing broken whitespace further down in the file (tabs->space). > > I'm still unclear how `--disable-manpages` is supposed to affect this logic, as they seemed to be the failing configs. @dholmes-ora That option is a bit weirdly named. It is used to enable new generation of man pages from markdown files instead of copying the static troff files. So without that option, this could not have failed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8618 From matthias.baesken at sap.com Tue May 10 11:52:17 2022 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 10 May 2022 11:52:17 +0000 Subject: VS2017 build errors jdk/jdk In-Reply-To: References: Message-ID: Hi Alan, thanks for the info . Casting to void* first also makes the compile issue go away : freeze_entry = (address)(void*)freeze; // If we wanted, we could templatize by kind and have three different thaw entries thaw_entry = (address)(void*)thaw; >So maybe it time to look at it, it might be easier to have a smaller set >of VS releases to support. On the other hand, having VS2017 for JDK11 - head is rather nice for backporting . Best regards, Matthias -----Original Message----- From: Alan Bateman Sent: Tuesday, 10 May 2022 13:16 To: Baesken, Matthias ; 'build-dev at openjdk.java.net' Cc: Zeller, Arno Subject: Re: VS2017 build errors jdk/jdk On 10/05/2022 09:29, Baesken, Matthias wrote: > Hello, it seems jdk/jdk does not build any more with VS2017. > Should we still support this compiler ? > > For the error see : > > https://bugs.openjdk.java.net/browse/JDK-8286459 > 8286459: compile error with VS2017 in continuationFreezeThaw.cpp > In Oracle, we moved from using VS2019 16.9.3 to VS2022 17.1.0 a few months ago. I checked the Microsoft site to get the status of VS2017. It says that the "Mainstream End Date" for that release was April 2022 so I guess it's not easy to get updates without extended support now. So maybe it time to look at it, it might be easier to have a smaller set of VS releases to support. -Alan From ihse at openjdk.java.net Tue May 10 11:58:47 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 10 May 2022 11:58:47 GMT Subject: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote: >> `make test TEST="gtest:> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Handle both 'cases' and 'suites' Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8605 From sgehwolf at openjdk.java.net Tue May 10 12:13:57 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 10 May 2022 12:13:57 GMT Subject: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote: >> `make test TEST="gtest:> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Handle both 'cases' and 'suites' Thanks for the review, Magnus. I'll wait until tomorrow for integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/8605 From erik.joelsson at oracle.com Tue May 10 12:57:16 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 10 May 2022 05:57:16 -0700 Subject: VS2017 build errors jdk/jdk In-Reply-To: References: Message-ID: On 2022-05-10 04:52, Baesken, Matthias wrote: >> So maybe it time to look at it, it might be easier to have a smaller set >> of VS releases to support. Because of how much specific logic we need in configure for each version of Visual Studio, we have generally kept configure support for older versions of VS for a long time, to not unnecessarily limit people. We removed 2015 and older when we moved to C++11 in Hotspot as 2017 or later was a hard requirement. Which compiler versions actually work depends on if anyone wants to keep up with the maintenance to keep them working. If VS2017 becomes unusable and nobody wants or is able to fix it, then I agree that we should remove support from configure. > On the other hand, having VS2017 for JDK11 - head is rather nice for backporting . Visual Studio allows side by side installations of multiple major versions. The OpenJDK configure script will pick one by default based on what's available, but you can also direct it with the parameter --with-toolchain-version=[2019|2017|2022]. /Erik > Best regards, Matthias > > > > -----Original Message----- > From: Alan Bateman > Sent: Tuesday, 10 May 2022 13:16 > To: Baesken, Matthias ; 'build-dev at openjdk.java.net' > Cc: Zeller, Arno > Subject: Re: VS2017 build errors jdk/jdk > > On 10/05/2022 09:29, Baesken, Matthias wrote: >> Hello, it seems jdk/jdk does not build any more with VS2017. >> Should we still support this compiler ? >> >> For the error see : >> >> https://bugs.openjdk.java.net/browse/JDK-8286459 >> 8286459: compile error with VS2017 in continuationFreezeThaw.cpp >> > In Oracle, we moved from using VS2019 16.9.3 to VS2022 17.1.0 a few > months ago. > > I checked the Microsoft site to get the status of VS2017. It says that > the "Mainstream End Date" for that release was April 2022 so I guess > it's not easy to get updates without extended support now. > > So maybe it time to look at it, it might be easier to have a smaller set > of VS releases to support. > > -Alan From erikj at openjdk.java.net Tue May 10 13:08:45 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 10 May 2022 13:08:45 GMT Subject: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote: >> `make test TEST="gtest:> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Handle both 'cases' and 'suites' Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8605 From erikj at openjdk.java.net Tue May 10 13:08:46 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 10 May 2022 13:08:46 GMT Subject: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't In-Reply-To: References: Message-ID: On Tue, 10 May 2022 08:42:10 GMT, Severin Gehwolf wrote: > Apparently gtest 1.8.1 uses `cases`. I've updated the patch to handle both: `suites` and `cases`. If somebody could test it with gtest 1.8.1 I'd appreciate it. Verified that it works with 1.8.1, which does indeed use `cases`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8605 From erikj at openjdk.java.net Tue May 10 13:12:48 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 10 May 2022 13:12:48 GMT Subject: Integrated: 8286429: jpackageapplauncher build fails intermittently in Tier[45] In-Reply-To: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> References: <1RGw84yPdsPp64KHIa4KBTZZdsj-7OJJQvmxj89aQyU=.b17b6d25-94d9-4102-b642-f532325f1326@github.com> Message-ID: <8UMdFeipdqWIxDhfLLXPj6kpM00206P5rsZEkY7WxLo=.1f51324b-dc1e-45cc-8e85-5ec4cdee62b0@github.com> On Mon, 9 May 2022 23:18:47 GMT, Erik Joelsson wrote: > The way LauncherCommon.gmk is currently written, it's only meant to be included from "make/module//Launcher.gmk", or at least only from one single place for each module. This is because the man page generation that happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, LauncherCommon.gmk is now called from two separate sub makefiles, both make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. These files are called from the top level targets jdk.jpackage-libs and jdk.jpackage-launchers respectively. These top level targets are assumed to be able to run independently of each other, which is normally fine, but now they define the same rules for the same files. This creates a race where one may be deleting files that the other one is creating, causing directories to disappear while files are being written to them. This can fail the build, but also risks silently corrupting the build. > > This patch fixes this by adding a conditional around the man page generation, which helps guarantee that man pages are only processed when called from make/module//Launcher.gmk. It's a bit of a hack, but it's building on top of the existing design of piggybacking man page generation on the launchers build. > > Also fixing broken whitespace further down in the file (tabs->space). This pull request has now been integrated. Changeset: 65f50678 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/65f50678f2fc9b129db57181f227ba0da53ecd38 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod 8286429: jpackageapplauncher build fails intermittently in Tier[45] Reviewed-by: asemenyuk, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/8618 From ysuenaga at openjdk.java.net Wed May 11 06:03:58 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 06:03:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings Message-ID: I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. As you can see, the warnings spreads several areas. Let me know if I should separate them by area. * -Wstringop-overflow * src/hotspot/share/oops/array.hpp * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: ------------- Commit messages: - 8286562: GCC 12 reports some compiler warnings Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286562 Stats: 63 lines in 13 files changed: 51 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From jrose at openjdk.java.net Wed May 11 06:28:37 2022 From: jrose at openjdk.java.net (John R Rose) Date: Wed, 11 May 2022 06:28:37 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v2] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Tue, 10 May 2022 09:07:44 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > 8244681: Add a warning for possibly lossy conversion in compound assignments > recommended correction of the warning wording > fixed typo in test method name src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 210: > 208: > 209: javac.opt.Xlint.desc.lossy-conversions=\ > 210: Warn about compiler possible lossy conversions. I like this warning. But the documentation doesn't even parse as English. I suggest this, as more grammatical and precise: > Warn about possible lossy conversions in compound assignments ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From Alan.Bateman at oracle.com Wed May 11 07:05:28 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2022 08:05:28 +0100 Subject: VS2017 build errors jdk/jdk In-Reply-To: References: Message-ID: <4834c6e0-51c3-b62c-5583-dd1f61b5de2e@oracle.com> On 10/05/2022 13:57, erik.joelsson at oracle.com wrote: > > Because of how much specific logic we need in configure for each > version of Visual Studio, we have generally kept configure support for > older versions of VS for a long time, to not unnecessarily limit > people. We removed 2015 and older when we moved to C++11 in Hotspot as > 2017 or later was a hard requirement. > > Which compiler versions actually work depends on if anyone wants to > keep up with the maintenance to keep them working. If VS2017 becomes > unusable and nobody wants or is able to fix it, then I agree that we > should remove support from configure. I don't think the logic in the build is the main concern, instead it's requiring all changes to shared + windows code to be buildable with VS2017 is a tax. So hopefully support for this version can be dropped soon. -Alan. From asotona at openjdk.java.net Wed May 11 07:45:39 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 07:45:39 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/6b3942b8..f0729396 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From ysuenaga at openjdk.java.net Wed May 11 08:40:21 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 08:40:21 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Avoid pragma error in before GCC 12 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/8154f6ea..7f155256 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From sgehwolf at openjdk.java.net Wed May 11 08:53:50 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 11 May 2022 08:53:50 GMT Subject: Integrated: 8286430: make test TEST="gtest:" exits with error when it shouldn't In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:39:28 GMT, Severin Gehwolf wrote: > `make test TEST="gtest: > Thoughts? This pull request has now been integrated. Changeset: 63a1ec6e Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/63a1ec6e7c08fc21d5cded734637eeb80147079f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8286430: make test TEST="gtest:" exits with error when it shouldn't Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8605 From mcimadamore at openjdk.java.net Wed May 11 10:39:44 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 11 May 2022 10:39:44 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v44] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits: - Merge branch 'master' into foreign-preview - Fix crashes in heap segment benchmarks due to misaligned access - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - ... and 54 more: https://git.openjdk.java.net/jdk/compare/73c5e993...cdd006e7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=43 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From jpai at openjdk.java.net Wed May 11 11:46:00 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 11 May 2022 11:46:00 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled Message-ID: Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? With this change the build now passes (tested both with bundled and system zlib variants). tier1, tier2 and tier3 testing has been done and no related failures have been noticed. ------------- Commit messages: - fix build issues with bundled zlib on macosx Changes: https://git.openjdk.java.net/jdk/pull/8651/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8651&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286582 Stats: 34 lines in 3 files changed: 30 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8651/head:pull/8651 PR: https://git.openjdk.java.net/jdk/pull/8651 From ihse at openjdk.java.net Wed May 11 11:50:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 11:50:50 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 The harfbuzz disabled warning looks good, so build changes are approved. You'll still need approval for the rest of the changes. While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From ihse at openjdk.java.net Wed May 11 11:59:43 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 11:59:43 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled In-Reply-To: References: Message-ID: On Wed, 11 May 2022 11:38:31 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? > > With this change the build now passes (tested both with bundled and system zlib variants). > > tier1, tier2 and tier3 testing has been done and no related failures have been noticed. Changes requested by ihse (Reviewer). make/autoconf/lib-bundled.m4 line 224: > 222: LIBZ_LIBS="" > 223: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then > 224: LIBZ_CFLAGS="$LIBZ_CFLAGS $APPLE_LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" Declaring APPLE_LIBZ_CFLAGS far away (and only conditionally) and then using it once here just makes for hard-to-read code. Suggestion: LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" if test "x$OPENJDK_TARGET_OS" = xmacosx; then LIBZ_CFLAGS="$LIBZ_CFLAGS -DHAVE_UNISTD_H" fi ... and remove the assignment above. src/java.base/share/native/libzip/zlib/gzwrite.c line 452: > 450: len = strlen(next); > 451: # else > 452: # ifdef __APPLE__ // ignore format-nonliteral warning on macOS Instead of patching 3rd party code to fix a compilation warning, you should disable that warning instead. In `make/modules/java.base/lib/CoreLibraries.gmk`, add DISABLED_WARNINGS_clang := format-nonliteral, \ as line 138. ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From ysuenaga at openjdk.java.net Wed May 11 12:38:58 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 12:38:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> References: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> Message-ID: On Wed, 11 May 2022 11:48:00 GMT, Magnus Ihse Bursie wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > The harfbuzz disabled warning looks good, so build changes are approved. You'll still need approval for the rest of the changes. > > While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... Thanks @magicus for your review! > While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... Agree, so I fixed bugs which were found out by compiler warnings in this PR - they are in libjli. I think we can ignore the others because they are already checked in other methods (e.g. `assert`), or due to structure of `Array` class which has payload in `_data[1]` (and it is also checked in `assert`). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Wed May 11 12:43:01 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 12:43:01 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: <2NpNw3Q9tkAShuydzhDKopMf3mLCyAwmSFoWzC665pI=.dbe3b460-d267-42ab-b08d-553bf133b796@github.com> On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 It is better to add pragma to `Array::at_put()` in src/hotspot/share/oops/array.hpp , but I couldn't suppress warnings. So I added pragmas to its caller - bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp . ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From alanb at openjdk.java.net Wed May 11 12:51:56 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 12:51:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; > 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 135: #pragma GCC diagnostic pop Can we just replace this code rather than putting pragmas here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jpai at openjdk.java.net Wed May 11 12:54:02 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 11 May 2022 12:54:02 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled In-Reply-To: References: Message-ID: On Wed, 11 May 2022 11:56:30 GMT, Magnus Ihse Bursie wrote: >> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system zlib variants). >> >> tier1, tier2 and tier3 testing has been done and no related failures have been noticed. > > src/java.base/share/native/libzip/zlib/gzwrite.c line 452: > >> 450: len = strlen(next); >> 451: # else >> 452: # ifdef __APPLE__ // ignore format-nonliteral warning on macOS > > Instead of patching 3rd party code to fix a compilation warning, you should disable that warning instead. > > In `make/modules/java.base/lib/CoreLibraries.gmk`, add > > DISABLED_WARNINGS_clang := format-nonliteral, \ > > as line 138. Thank you for these useful inputs Magnus. I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library. I will investigate and see what's going on. Will update the PR once I figure it out. ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From alanb at openjdk.java.net Wed May 11 12:54:03 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 12:54:03 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled In-Reply-To: References: Message-ID: <1VProTCyDpN_GDpPOkBynPmEjGkNhicS7ZINpTLYAdo=.654b6689-d3e1-42ca-b4d6-e0c324a3ce45@github.com> On Wed, 11 May 2022 12:47:08 GMT, Jaikiran Pai wrote: >> src/java.base/share/native/libzip/zlib/gzwrite.c line 452: >> >>> 450: len = strlen(next); >>> 451: # else >>> 452: # ifdef __APPLE__ // ignore format-nonliteral warning on macOS >> >> Instead of patching 3rd party code to fix a compilation warning, you should disable that warning instead. >> >> In `make/modules/java.base/lib/CoreLibraries.gmk`, add >> >> DISABLED_WARNINGS_clang := format-nonliteral, \ >> >> as line 138. > > Thank you for these useful inputs Magnus. I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library. I will investigate and see what's going on. Will update the PR once I figure it out. I agree with Magnus and try to avoid changing the imported zlib code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From ihse at openjdk.java.net Wed May 11 13:05:46 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 13:05:46 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > 8244681: Add a warning for possibly lossy conversion in compound assignments > recommended correction of the warning description Check updates on JDK-8286374 subtasks. make/modules/jdk.jfr/Java.gmk line 26: > 24: # > 25: > 26: DISABLED_WARNINGS_java += exports lossy-conversions Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix. (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.) ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8599 From egahlin at openjdk.java.net Wed May 11 13:05:46 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 11 May 2022 13:05:46 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > 8244681: Add a warning for possibly lossy conversion in compound assignments > recommended correction of the warning description Lossy conversion issues for jdk.jfr and jdk.management.jfr. have been fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From egahlin at openjdk.java.net Wed May 11 13:08:49 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 11 May 2022 13:08:49 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> On Wed, 11 May 2022 12:59:49 GMT, Magnus Ihse Bursie wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> 8244681: Add a warning for possibly lossy conversion in compound assignments >> recommended correction of the warning description > > make/modules/jdk.jfr/Java.gmk line 26: > >> 24: # >> 25: >> 26: DISABLED_WARNINGS_java += exports lossy-conversions > > Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. > > In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix. > > (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.) I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From ihse at openjdk.java.net Wed May 11 13:13:43 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 13:13:43 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> Message-ID: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin wrote: >> make/modules/jdk.jfr/Java.gmk line 26: >> >>> 24: # >>> 25: >>> 26: DISABLED_WARNINGS_java += exports lossy-conversions >> >> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. >> >> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix. >> >> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.) > > I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement. That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From ysuenaga at openjdk.java.net Wed May 11 13:24:38 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 13:24:38 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:48:38 GMT, Alan Bateman wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; >> 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 135: #pragma GCC diagnostic pop > > Can we just replace this code rather than putting pragmas here? I tried several patterns, but I couldn't find out a solution other than pragmas. Do you have any ideas? For example: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) < sizeof(name)) { JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); } else { return 0; } Compiler warnings: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From asotona at openjdk.java.net Wed May 11 13:30:43 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 13:30:43 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> Message-ID: On Wed, 11 May 2022 13:10:10 GMT, Magnus Ihse Bursie wrote: >> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement. > > That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue. Thanks for quick reaction. I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From rriggs at openjdk.java.net Wed May 11 13:34:49 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 11 May 2022 13:34:49 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> Message-ID: On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona wrote: >> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue. > > Thanks for quick reaction. > I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR. I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From kbarrett at openjdk.java.net Wed May 11 14:01:52 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 11 May 2022 14:01:52 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 Changes requested by kbarrett (Reviewer). make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: > 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing > 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ > 462: maybe-uninitialized class-memaccess unused-result extra use-after-free Globally disabling use-after-free warnings for this package seems really questionable. If these are problems in the code, just suppressing the warning and leaving the problems to bite us seems like a bad idea. And the problems ought to be reported upstream to the HarfBuzz folks. src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51: > 49: > 50: #define PRAGMA_STRINGOP_OVERFLOW_IGNORED \ > 51: PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") Are the reported problems with format/stringop-overflow real? Or are they false positives? If they are real then I'm not going to approve ignoring them, unless there is some urgent reason and there are followup bug reports for fixing them. src/java.base/share/native/libjli/java.c line 1629: > 1627: const char *arg = jargv[i]; > 1628: if (arg[0] == '-' && arg[1] == 'J') { > 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); Wow! src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; > 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 135: #pragma GCC diagnostic pop Wouldn't it be better to just call JLI_Snprintf without the precheck and check the result to determine whether it was successful or was truncated? I think that kind of check is supposed to make gcc's truncation checker happy. src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193: > 191: #if defined(__GNUC__) && __GNUC__ >= 12 > 192: #pragma GCC diagnostic pop > 193: #endif Rather than all this warning suppression cruft and the comment explaining why it's okay, just compute the `(strBufNextChar - strBufBegin)` offset a few lines earlier, before the realloc. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From chen.j.patrick at gmail.com Wed May 11 14:08:28 2022 From: chen.j.patrick at gmail.com (Patrick Chen) Date: Wed, 11 May 2022 16:08:28 +0200 Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> Message-ID: I checked you pr look good to me @Roger Le mer. 11 mai 2022 ? 15:35, Roger Riggs a ?crit : > On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona wrote: > > >> That's good to know. I think the tricky part is mostly about keeping > track of all these disabled warnings, so they are not kept around longer > than necessary. And that needs coordination with all the subtasks of the > umbrella issue. > > > > Thanks for quick reaction. > > I'll keep my eyes on this race of patches and update this pull request > accordingly or create a new PR. > > I put out a PR for java.base, but thought I'd wait until the javac fixe > were pushed before integrating and would re-enable the warnings at the same > time. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/8599 > From jpai at openjdk.java.net Wed May 11 14:24:38 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 11 May 2022 14:24:38 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? > > With this change the build now passes (tested both with bundled and system zlib variants). > > tier1, tier2 and tier3 testing has been done and no related failures have been noticed. Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: - copyright years - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8651/files - new: https://git.openjdk.java.net/jdk/pull/8651/files/eee12c25..081a7d34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8651&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8651&range=00-01 Stats: 41 lines in 5 files changed: 5 ins; 30 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8651/head:pull/8651 PR: https://git.openjdk.java.net/jdk/pull/8651 From kbarrett at openjdk.java.net Wed May 11 14:31:02 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 11 May 2022 14:31:02 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:56:44 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/share/native/libjli/java.c line 1629: > >> 1627: const char *arg = jargv[i]; >> 1628: if (arg[0] == '-' && arg[1] == 'J') { >> 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); > > Wow! I wonder if the client expects NULL strings in the result, or if the NULL value should be an empty string? If empty strings are okay, this would be simpler without the conditional, just dup from arg + 2 to the terminating byte (which might be immediate). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jpai at openjdk.java.net Wed May 11 14:32:48 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 11 May 2022 14:32:48 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 11:52:55 GMT, Magnus Ihse Bursie wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: >> >> - copyright years >> - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib >> - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file >> - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code > > make/autoconf/lib-bundled.m4 line 224: > >> 222: LIBZ_LIBS="" >> 223: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then >> 224: LIBZ_CFLAGS="$LIBZ_CFLAGS $APPLE_LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" > > Declaring APPLE_LIBZ_CFLAGS far away (and only conditionally) and then using it once here just makes for hard-to-read code. > > Suggestion: > > LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" > if test "x$OPENJDK_TARGET_OS" = xmacosx; then > LIBZ_CFLAGS="$LIBZ_CFLAGS -DHAVE_UNISTD_H" > fi > > ... and remove the assignment above. Updated the PR to implement this suggestion ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From jpai at openjdk.java.net Wed May 11 14:32:48 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 11 May 2022 14:32:48 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: <1VProTCyDpN_GDpPOkBynPmEjGkNhicS7ZINpTLYAdo=.654b6689-d3e1-42ca-b4d6-e0c324a3ce45@github.com> References: <1VProTCyDpN_GDpPOkBynPmEjGkNhicS7ZINpTLYAdo=.654b6689-d3e1-42ca-b4d6-e0c324a3ce45@github.com> Message-ID: On Wed, 11 May 2022 12:50:39 GMT, Alan Bateman wrote: >> Thank you for these useful inputs Magnus. I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library. I will investigate and see what's going on. Will update the PR once I figure it out. > > I agree with Magnus and try to avoid changing the imported zlib code. > I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library. Turns out that was slightly inaccurate. What was actually happening was that, that setting you suggested in that build file did indeed work and got picked up. But it ran into an error which looked like: src/java.base/share/native/libzip/zlib/gzwrite.c:452:40: error: format string is not a string literal [-Werror,-Wformat-nonliteral] len = vsnprintf(next, state->size, format, va); ^~~~~~ ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From asotona at openjdk.java.net Wed May 11 13:41:30 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 13:41:30 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v4] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <3RgMbsaSwgdBXE2qlIwjVI680aN7Ovi6OOfu9eeNtJo=.a76eff60-8652-40ce-ae40-20f9095b1b93@github.com> > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona 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 six additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments jdk.internal.le make patch to disable warnings - 8244681: Add a warning for possibly lossy conversion in compound assignments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/f0729396..a59dfa4f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02-03 Stats: 9179 lines in 255 files changed: 5253 ins; 2422 del; 1504 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Wed May 11 13:41:30 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 13:41:30 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> Message-ID: <6EkEbNxPc3RKNGprHlBhqM574oY7iPI9z3PpR91IMok=.9019963f-8085-49a8-951f-f8a2b2137fb0@github.com> On Wed, 11 May 2022 13:31:16 GMT, Roger Riggs wrote: >> Thanks for quick reaction. >> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR. > > I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time. Feel free to go ahead with the java.base PR as this one still needs CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Wed May 11 14:45:12 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 14:45:12 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v5] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/a59dfa4f..32282515 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From lancea at openjdk.java.net Wed May 11 15:03:47 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 11 May 2022 15:03:47 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: <1VProTCyDpN_GDpPOkBynPmEjGkNhicS7ZINpTLYAdo=.654b6689-d3e1-42ca-b4d6-e0c324a3ce45@github.com> Message-ID: <8QwcHX46TZ4lK5rWWftn_gzLbN7ErqkeV2wz1wGlOMw=.63e28371-2f39-4699-83db-3ffb447c6f8f@github.com> On Wed, 11 May 2022 14:25:39 GMT, Jaikiran Pai wrote: >> I agree with Magnus and try to avoid changing the imported zlib code. > >> I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library. > > Turns out that was slightly inaccurate. What was actually happening was that, that setting you suggested in that build file did indeed work and got picked up. But it ran into an error which looked like: > > > src/java.base/share/native/libzip/zlib/gzwrite.c:452:40: error: format string is not a string literal [-Werror,-Wformat-nonliteral] > len = vsnprintf(next, state->size, format, va); > ^~~~~~ > I agree with Magnus and try to avoid changing the imported zlib code. We already had modified gzwrite.c in our port so I thought keeping the changes narrowed to apple made sense here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From lancea at openjdk.java.net Wed May 11 15:12:05 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 11 May 2022 15:12:05 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system zlib variants). >> >> tier1, tier2 and tier3 testing has been done and no related failures have been noticed. > > Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: > > - copyright years > - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib > - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file > - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code Hi Jai, thank you for continuing the work to allow us to build/use the bundled zlib on macOS we should also update: open/src/java.base/share/native/libzip/zlib/ChangeLog to add a comment regarding why the build changes were required make/autoconf/lib-bundled.m4 line 220: > 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then > 219: LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" > 220: if test "x$OPENJDK_TARGET_OS" = xmacosx; then Please add a comment here as to why we are doing this make/modules/java.base/lib/CoreLibraries.gmk line 139: > 137: DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \ > 138: DISABLED_WARNINGS_clang := format-nonliteral, \ > 139: LDFLAGS := $(LDFLAGS_JDKLIB) \ A comment would be good here also as to the reasoning make/modules/java.desktop/lib/Awt2dLibraries.gmk line 683: > 681: ifeq ($(USE_EXTERNAL_LIBZ), false) > 682: LIBSPLASHSCREEN_EXTRA_SRC += java.base:libzip/zlib > 683: LIBZ_DISABLED_WARNINGS_CLANG := format-nonliteral Same here for a comment ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From mkartashev at openjdk.java.net Wed May 11 16:03:54 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Wed, 11 May 2022 16:03:54 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From magnus.ihse.bursie at oracle.com Wed May 11 18:02:45 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 11 May 2022 20:02:45 +0200 Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On 2022-05-11 16:01, Kim Barrett wrote: > Globally disabling use-after-free warnings for this package seems really > questionable. If these are problems in the code, just suppressing the warning > and leaving the problems to bite us seems like a bad idea. And the problems > ought to be reported upstream to the HarfBuzz folks. I agree that an upstream report would be nice, but it has been a long-standing policy of not changing 3rd party code to fix warnings, but instead suppress them. (Most of the time we compile with a much larger set of warnings enabled than the upstream's own build does, so we trigger warnings they never even see.) /Magnus From ihse at openjdk.java.net Wed May 11 18:11:47 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 18:11:47 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system zlib variants). >> >> tier1, tier2 and tier3 testing has been done and no related failures have been noticed. > > Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: > > - copyright years > - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib > - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file > - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code Looks good to me. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8651 From ihse at openjdk.java.net Wed May 11 18:11:48 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 18:11:48 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: >> >> - copyright years >> - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib >> - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file >> - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code > > make/autoconf/lib-bundled.m4 line 220: > >> 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then >> 219: LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" >> 220: if test "x$OPENJDK_TARGET_OS" = xmacosx; then > > Please add a comment here as to why we are doing this @LanceAndersen Is that really needed? We normally don't comment on the reason why certain code needs certain defines. We tried to document some compiler flags in the beginning, but it turned out that most command lines ended up as essays, and this were not helpful. I think it's quite obvious what this code does: libz requires the define HAVE_UNISTD_H on macOS. I'm not even sure how you'd formulate a "why" -- "otherwise it does not work properly"? > make/modules/java.base/lib/CoreLibraries.gmk line 139: > >> 137: DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \ >> 138: DISABLED_WARNINGS_clang := format-nonliteral, \ >> 139: LDFLAGS := $(LDFLAGS_JDKLIB) \ > > A comment would be good here also as to the reasoning And once again, we never comment on why we disable warnings. The context is clear enough -- there is a compiler warning that is not applicable to this module. Especially for 3rd party code, which is not nearly as stringent as we are about enabling warnings. ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From prr at openjdk.java.net Wed May 11 19:14:03 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 19:14:03 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:35:00 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: > >> 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing >> 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ >> 462: maybe-uninitialized class-memaccess unused-result extra use-after-free > > Globally disabling use-after-free warnings for this package seems really > questionable. If these are problems in the code, just suppressing the warning > and leaving the problems to bite us seems like a bad idea. And the problems > ought to be reported upstream to the HarfBuzz folks. I don't understand what the actual warning is getting at .. can anyone explain it ? FWIW the code is still the same in upstream harfbuzz https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From lancea at openjdk.java.net Wed May 11 19:18:49 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 11 May 2022 19:18:49 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: Message-ID: <8P-ZnuJlg11CfrjiE1H5TBXSO90Yc720GVglwIEO3oU=.de7c3c64-6fb9-4eb3-9753-c608732ebcaa@github.com> On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: >> >> - copyright years >> - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib >> - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file >> - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code > > make/autoconf/lib-bundled.m4 line 220: > >> 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then >> 219: LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" >> 220: if test "x$OPENJDK_TARGET_OS" = xmacosx; then > > Please add a comment here as to why we are doing this > @LanceAndersen Is that really needed? We normally don't comment on the reason why certain code needs certain defines. We tried to document some compiler flags in the beginning, but it turned out that most command lines ended up as essays, and this were not helpful. I think it's quite obvious what this code does: libz requires the define HAVE_UNISTD_H on macOS. I'm not even sure how you'd formulate a "why" -- "otherwise it does not work properly"? The zlib configure script, which needs to be run prior running make to build the upstream repository, will determine if HAVE_UNISTD_H is needed and generate zconf.h replacing the macro with "1". My reason for adding a comment as this is a variant from how zlib is built upstream. Perhaps just updating open/src/java.base/share/native/libzip/zlib/ChangeLog is enough. I was just trying to document why we are doing this. Another question would it make sense to set LIBZ_DISABLED_WARNINGS_CLANG in make/autoconf/lib-bundled.m4 so that the value in the case of zlib is set in one location? In addition, I can log a request to address this in the upstream project so we do not need to worry about this warning going forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From afarley at openjdk.java.net Wed May 11 21:02:08 2022 From: afarley at openjdk.java.net (Adam Farley) Date: Wed, 11 May 2022 21:02:08 GMT Subject: RFR: 8286601: Mac Aarch: Excessive warnings to be ignored for build jdk Message-ID: These warnings are ignored while building the build+full jdks with gcc, but only ignored while building the full JDK if using clang. This produces tons of warnings we normally ignore, e.g. unused parameter. I suggest that if we're ignoring this type of error while using gcc, we should also ignore them while using clang. Signed-off-by: Adam Farley ------------- Commit messages: - 8286601: Mac Aarch: Excessive warnings to be ignored for build jdk Changes: https://git.openjdk.java.net/jdk/pull/8665/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8665&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286601 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8665.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8665/head:pull/8665 PR: https://git.openjdk.java.net/jdk/pull/8665 From erikj at openjdk.java.net Wed May 11 21:14:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 11 May 2022 21:14:54 GMT Subject: RFR: 8286601: Mac Aarch: Excessive warnings to be ignored for build jdk In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:55:29 GMT, Adam Farley wrote: > These warnings are ignored while building the build+full jdks with gcc, > but only ignored while building the full JDK if using clang. This > produces tons of warnings we normally ignore, e.g. unused parameter. > > I suggest that if we're ignoring this type of error while using gcc, > we should also ignore them while using clang. > > Signed-off-by: Adam Farley Looks good. This looks like an oversight. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8665 From ihse at openjdk.java.net Wed May 11 22:06:55 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 22:06:55 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: <8P-ZnuJlg11CfrjiE1H5TBXSO90Yc720GVglwIEO3oU=.de7c3c64-6fb9-4eb3-9753-c608732ebcaa@github.com> References: <8P-ZnuJlg11CfrjiE1H5TBXSO90Yc720GVglwIEO3oU=.de7c3c64-6fb9-4eb3-9753-c608732ebcaa@github.com> Message-ID: On Wed, 11 May 2022 19:14:54 GMT, Lance Andersen wrote: >> make/autoconf/lib-bundled.m4 line 220: >> >>> 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then >>> 219: LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" >>> 220: if test "x$OPENJDK_TARGET_OS" = xmacosx; then >> >> Please add a comment here as to why we are doing this > >> @LanceAndersen Is that really needed? We normally don't comment on the reason why certain code needs certain defines. We tried to document some compiler flags in the beginning, but it turned out that most command lines ended up as essays, and this were not helpful. I think it's quite obvious what this code does: libz requires the define HAVE_UNISTD_H on macOS. I'm not even sure how you'd formulate a "why" -- "otherwise it does not work properly"? > > The zlib configure script, which needs to be run prior running make to build the upstream repository, will determine if HAVE_UNISTD_H is needed and generate zconf.h replacing the macro with "1". My reason for adding a comment as this is a variant from how zlib is built upstream. Perhaps just updating open/src/java.base/share/native/libzip/zlib/ChangeLog is enough. I was just trying to document why we are doing this. > > > Another question would it make sense to set LIBZ_DISABLED_WARNINGS_CLANG in make/autoconf/lib-bundled.m4 so that the value in the case of zlib is set in one location? In addition, I can log a request to address this in the upstream project so we do not need to worry about this warning going forward. It would not make sense to set the disabled warning in the configure script, no. The current code looks perfectly fine. Disabled warnings per module are set in the makefiles. If you feel strongly that this needs to be documented more than in the JBS issue and this PR review, updating the zlib ChangeLog file is probably the way to go. I have no strong opinion on that. But from the build system PoV, the current code is fine as it is to be committed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From lancea at openjdk.java.net Wed May 11 22:25:03 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 11 May 2022 22:25:03 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: Message-ID: <7v43S0cpiMtx_4IQPS8ERo-ynpc-V5Q7_kDAGYzB78g=.f691bf42-60e3-42c4-93a0-dcba5079574a@github.com> On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system zlib variants). >> >> tier1, tier2 and tier3 testing has been done and no related failures have been noticed. > > Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: > > - copyright years > - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib > - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file > - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code Thanks Jai for the latest tweaks to the our original patch. I think we should be good to go ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8651 From lancea at openjdk.java.net Wed May 11 22:25:05 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 11 May 2022 22:25:05 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: <8P-ZnuJlg11CfrjiE1H5TBXSO90Yc720GVglwIEO3oU=.de7c3c64-6fb9-4eb3-9753-c608732ebcaa@github.com> Message-ID: On Wed, 11 May 2022 22:03:38 GMT, Magnus Ihse Bursie wrote: > It would not make sense to set the disabled warning in the configure script, no. The current code looks perfectly fine. Disabled warnings per module are set in the makefiles. OK, that you for your feedback regarding the makefile changes vs. configure script. > > If you feel strongly that this needs to be documented more than in the JBS issue and this PR review, updating the zlib ChangeLog file is probably the way to go. I have no strong opinion on that. But from the build system PoV, the current code is fine as it is to be committed. OK, I am probably overthinking the need to document this ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From afarley at openjdk.java.net Wed May 11 22:58:46 2022 From: afarley at openjdk.java.net (Adam Farley) Date: Wed, 11 May 2022 22:58:46 GMT Subject: RFR: 8286601: Mac Aarch: Excessive warnings to be ignored for build jdk In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:55:29 GMT, Adam Farley wrote: > These warnings are ignored while building the build+full jdks with gcc, > but only ignored while building the full JDK if using clang. This > produces tons of warnings we normally ignore, e.g. unused parameter. > > I suggest that if we're ignoring this type of error while using gcc, > we should also ignore them while using clang. > > Signed-off-by: Adam Farley P.S. The "macOS aarch64 - Build" check seems to have failed because it lost connection to the server mid-build. I don't think this was related to the fix. Still, of all the platforms to fail. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8665 From ysuenaga at openjdk.java.net Thu May 12 00:29:47 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 00:29:47 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 19:11:16 GMT, Phil Race wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: >> >>> 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing >>> 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ >>> 462: maybe-uninitialized class-memaccess unused-result extra use-after-free >> >> Globally disabling use-after-free warnings for this package seems really >> questionable. If these are problems in the code, just suppressing the warning >> and leaving the problems to bite us seems like a bad idea. And the problems >> ought to be reported upstream to the HarfBuzz folks. > > I don't understand what the actual warning is getting at .. can anyone explain it ? > > FWIW the code is still the same in upstream harfbuzz > https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc I've pasted a part of warning messages to description of this PR, all of messages are here: In function 'void trampoline_reference(hb_trampoline_closure_t*)', inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*, hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 00:38:34 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 00:38:34 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:35:43 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51: > >> 49: >> 50: #define PRAGMA_STRINGOP_OVERFLOW_IGNORED \ >> 51: PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") > > Are the reported problems with format/stringop-overflow real? Or are they > false positives? If they are real then I'm not going to approve ignoring them, > unless there is some urgent reason and there are followup bug reports for > fixing them. I think all of warnings in HotSpot are false-positives, so I added new pragmas to compilerWarnings.hpp, and use it in HotSpot code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:11:39 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:11:39 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:27:27 GMT, Kim Barrett wrote: >> src/java.base/share/native/libjli/java.c line 1629: >> >>> 1627: const char *arg = jargv[i]; >>> 1628: if (arg[0] == '-' && arg[1] == 'J') { >>> 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); >> >> Wow! > > I wonder if the client expects NULL strings in the result, or if the NULL value should be an empty string? If empty strings are okay, this would be simpler without the conditional, just dup from arg + 2 to the terminating byte (which might be immediate). `NULL` affects as a loop stopper in `ParseArguments()` as following: static jboolean ParseArguments(int *pargc, char ***pargv, int *pmode, char **pwhat, int *pret, const char *jrepath) { int argc = *pargc; char **argv = *pargv; int mode = LM_UNKNOWN; char *arg; *pret = 0; while ((arg = *argv) != 0 && *arg == '-') { But I'm not sure it is valid, I think it might be discussed as another issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:17:36 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:17:36 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v3] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Use return value from JLI_Snprintf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/7f155256..8d608414 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=01-02 Stats: 11 lines in 1 file changed: 4 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:17:37 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:17:37 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:43:55 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; >> 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 135: #pragma GCC diagnostic pop > > Wouldn't it be better to just call JLI_Snprintf without the precheck and check the result to determine whether it was successful or was truncated? I think that kind of check is supposed to make gcc's truncation checker happy. The warning has gone when using return value from `JLI_Snprintf()` in new commit! ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:27:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:27:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Calculate char offset before realloc() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/8d608414..b3afa3e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=02-03 Stats: 18 lines in 1 file changed: 3 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:27:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:27:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:47:43 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193: > >> 191: #if defined(__GNUC__) && __GNUC__ >= 12 >> 192: #pragma GCC diagnostic pop >> 193: #endif > > Rather than all this warning suppression cruft and the comment explaining why > it's okay, just compute the `(strBufNextChar - strBufBegin)` offset a few > lines earlier, before the realloc. I did do that in new commit, and the warning has gone! ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:32:42 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:32:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Calculate char offset before realloc() Thanks for all to review this PR! I think we should separate this issue as following: * Suppress warnings * make/modules/java.desktop/lib/Awt2dLibraries.gmk * src/hotspot/share/classfile/bytecodeAssembler.cpp * src/hotspot/share/classfile/classFileParser.cpp * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp * src/hotspot/share/opto/memnode.cpp * src/hotspot/share/opto/type.cpp * src/hotspot/share/utilities/compilerWarnings.hpp * src/hotspot/share/utilities/compilerWarnings_gcc.hpp * src/java.base/unix/native/libjli/java_md_common.c * Bug fixes * src/java.base/share/native/libjli/java.c * src/java.base/share/native/libjli/parse_manifest.c * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jpai at openjdk.java.net Thu May 12 02:52:40 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 12 May 2022 02:52:40 GMT Subject: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system zlib variants). >> >> tier1, tier2 and tier3 testing has been done and no related failures have been noticed. > > Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: > > - copyright years > - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib > - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file > - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code Thank you Lance and Magnus for the reviews and inputs. I've triggered various build and test runs with this state of the PR. Once those complete satisfactorily, I'll go ahead and integrate this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From dholmes at openjdk.java.net Thu May 12 04:28:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 04:28:43 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust API level to Windows 8 for security.cpp and do some cleanup > > This change seem to have made this group of declarations obsolete: > `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( > https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. @mkartashev all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Thu May 12 07:31:50 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 12 May 2022 07:31:50 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: > This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link](https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. Hi Maxim, no plans from me, so feel free to do further cleanups. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From jpai at openjdk.java.net Thu May 12 08:13:56 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 12 May 2022 08:13:56 GMT Subject: Integrated: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled In-Reply-To: References: Message-ID: On Wed, 11 May 2022 11:38:31 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`? > > With this change the build now passes (tested both with bundled and system zlib variants). > > tier1, tier2 and tier3 testing has been done and no related failures have been noticed. This pull request has now been integrated. Changeset: 50d47de8 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/50d47de8358e2f22bf3a4a165d660c25ef6eacbc Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod 8286582: Build fails on macos aarch64 when using --with-zlib=bundled Reviewed-by: ihse, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/8651 From jpai at openjdk.java.net Thu May 12 08:51:23 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 12 May 2022 08:51:23 GMT Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64 Message-ID: Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64. ------------- Commit messages: - jib profile - don't explicitly set system zlib for macosx-aarch64 - default to bundled zlib on macos aarch64 Changes: https://git.openjdk.java.net/jdk/pull/8675/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8675&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286623 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8675.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8675/head:pull/8675 PR: https://git.openjdk.java.net/jdk/pull/8675 From jpai at openjdk.java.net Thu May 12 08:56:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 12 May 2022 08:56:49 GMT Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64 In-Reply-To: References: Message-ID: On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. > We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64. Dummy comment to initiate a mail to core-libs mailing list too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8675 From afarley at openjdk.java.net Thu May 12 09:30:49 2022 From: afarley at openjdk.java.net (Adam Farley) Date: Thu, 12 May 2022 09:30:49 GMT Subject: Integrated: 8286601: Mac Aarch: Excessive warnings to be ignored for build jdk In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:55:29 GMT, Adam Farley wrote: > These warnings are ignored while building the build+full jdks with gcc, > but only ignored while building the full JDK if using clang. This > produces tons of warnings we normally ignore, e.g. unused parameter. > > I suggest that if we're ignoring this type of error while using gcc, > we should also ignore them while using clang. > > Signed-off-by: Adam Farley This pull request has now been integrated. Changeset: 40f43c6b Author: Adam Farley Committer: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8286601: Mac Aarch: Excessive warnings to be ignored for build jdk Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8665 From magnus.ihse.bursie at oracle.com Thu May 12 09:42:15 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 May 2022 11:42:15 +0200 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: References: Message-ID: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> (cc:ing build-dev.) On 2022-05-12 00:17, Michael Hall wrote: > Is this restricted somehow to Mac App Store applications? > > Is a warning issued as stripping native commands may break application functionality? > > Is it not possible for the user to provide their own Info.plist with a different bundle identifier that doesn?t collide? > > I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded? This problem seem to come about as a clash between the the OpenJDK packages themselves being submitted to Apple, as well as a developer-specific jpackage containing JDK binaries, such as java. The well-written response from Apple tech support in the original web bug is very instructive. I'll quote it in its entirety: ---- > I?ve dealt with this message before, and it has a long and interesting > history. The Mac App Store prevents two developers from submitting > executables with the same bundle identifier. This is an important > security check: We don?t want app A impersonating app B. > > This check applies to all executables, not just the app?s main > executable. Historically the Mac App Store ingestion process had bugs > that caused it to apply to other types of code, like frameworks and > bundles. When I first saw this incident I was worried that these bugs > had come back. > > However, that?s not the case. Let?s look at the main executables in > your app: > > % find APP_NAME.app -type f -print0 | xargs -0 file | grep > "Mach-O.*executable" > APP_NAME.app/Contents/MacOS/APP_NAME: Mach-O 64-bit executable x86_64 > APP_NAME.app/Contents/runtime/Contents/Home/bin/java: Mach-O 64-bit > executable x86_64 > APP_NAME.app/Contents/runtime/Contents/Home/bin/keytool: Mach-O 64-bit > executable x86_64 > APP_NAME.app/Contents/runtime/Contents/Home/lib/jspawnhelper: Mach-O > 64-bit executable x86_64 > > Based on the error message it?s obvious we need to focus on the `java` > executable. However, it?s placed in a location that doesn?t have a > corresponding `Info.plist` file: > > % find APP_NAME.app -name "Info.plist" > APP_NAME.app/Contents/Info.plist > APP_NAME.app/Contents/runtime/Contents/Info.plist > > The first file here applies to your entire app and the second file > applies to the Java runtime package as a whole. Moreover, neither of > these have a bundle ID that matches the error message: > > % plutil -extract CFBundleIdentifier raw -o - > "APP_NAME.app/Contents/Info.plist" > UNIQUE.BUNDLE.ID > % plutil -extract CFBundleIdentifier raw -o - > "APP_NAME.app/Contents/runtime/Contents/Info.plist" > com.oracle.java.com.UNIQUE.BUNDLE.ID > > So where is this bundle ID coming from? > > * * * > > Some further spelunking reveals the issue. Consider this: > > % otool -s __TEXT __info_plist -v > APP_NAME.app/Contents/runtime/Contents/Home/bin/java > ? > > CFBundleIdentifier > net.java.openjdk.java > ? > > > > This is an obscure corner case in the macOS bundle story: A standalone > tool, like `java`, which isn?t in a bundle structure, and thus can?t > have a standalone `Info.plist` file, can put its information property > list in a `__TEXT` / `__info_plist` section within its executable. And > it seems that the folks who created your Java runtime did just that. > > Given that, the Mac App Store error is valid: You are trying to submit > an executable whose bundle ID matches some existing app. > > To get around this check you?ll need to give `java` a new bundle ID. > That?s not easy to do. This `__TEXT` / `__info_plist` section is set > up by a linker option (see `-sectcreate` in )> and there?s no good way to modify it after the > fact [1]. > > At this point my advice is that you escalate this with your Java > runtime vendor. I suspect that they?ve added this information property > list to get around a TCC check ? the only other interesting property > in there is `NSMicrophoneUsageDescription` ? and they probably didn?t > notice this Mac App Store submission issue. There?s a couple of ways > they could resolve this [2] but it?s really their issue to resolve. > > [1] And by ?good? I mean ?Using a standard tool supplied by Apple.? > The Mach-O file format is reasonably well documented and thus you > could build a custom tool to do that, but even that?s not easy. There > are a couple of problems: > > * The new information property list may be larger than the previous one. > > * The `__info_plist` section can appear anywhere in the `__TEXT` segment. > > If you increase the size of the section then subsequent sections need > to move up to accommodate it and, depending on which sections you have > to move, that might require other cross-section links to be fixed up. > Yergh! > > [2] The ones that spring to mind are: > > * Package the `java` executable in a standard bundle, replacing > `runtime/Contents/Home/bin/java` with a symlink to that. > > * Add an `__info_plist` section with a bunch of padding and then build > a tool to update the bundle ID in that section, taking advantage of > that padding to avoid the need to move subsequent sections in the > `__TEXT` segment. ---- So maybe a better, or at least alternative, way of dealing with this issue is changing how the OpenJDK binaries are built. I will need to do some reading up on the macOS bundle format to fully grok what our options are here. /Magnus From lancea at openjdk.java.net Thu May 12 10:28:07 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 12 May 2022 10:28:07 GMT Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64 In-Reply-To: References: Message-ID: On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. > We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64. Hi Jai, Thank you for your efforts with testing and reaching out to Apple. Given we do not see the issue with the bundled zlib, this is our best path forward for stability on macOS aarch64. Once we can determine the cause with the help of Apple, we can switch back to the zlib that comes with macOS on this platform. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8675 From ihse at openjdk.java.net Thu May 12 10:39:56 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 12 May 2022 10:39:56 GMT Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64 In-Reply-To: References: Message-ID: On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. > We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64. LGTM ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8675 From mkartashev at openjdk.java.net Thu May 12 11:00:49 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 12 May 2022 11:00:49 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Thu, 12 May 2022 04:25:24 GMT, David Holmes wrote: >> This change seem to have made this group of declarations obsolete: >> `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( >> https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. > > @mkartashev all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced. @dholmes-ora @MBaesken Thank you! Filed [JDK-8286634](https://bugs.openjdk.java.net/browse/JDK-8286634). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ihse at openjdk.java.net Thu May 12 11:04:08 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 12 May 2022 11:04:08 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Calculate char offset before realloc() > > Thanks for all to review this PR! I think we should separate this issue as following: > > * Suppress warnings > * make/modules/java.desktop/lib/Awt2dLibraries.gmk > * src/hotspot/share/classfile/bytecodeAssembler.cpp > * src/hotspot/share/classfile/classFileParser.cpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > * src/hotspot/share/opto/memnode.cpp > * src/hotspot/share/opto/type.cpp > * src/hotspot/share/utilities/compilerWarnings.hpp > * src/hotspot/share/utilities/compilerWarnings_gcc.hpp > * src/java.base/unix/native/libjli/java_md_common.c > * Bug fixes > * src/java.base/share/native/libjli/java.c > * src/java.base/share/native/libjli/parse_manifest.c > * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c > > I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. > > I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. @YaSuenag From my PoV this sounds like a good suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From mik3hall at gmail.com Thu May 12 11:17:10 2022 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 12 May 2022 06:17:10 -0500 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> References: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> Message-ID: <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com> > On May 12, 2022, at 4:42 AM, Magnus Ihse Bursie wrote: > >> Some further spelunking reveals the issue. Consider this: >> >> % otool -s __TEXT __info_plist -v APP_NAME.app/Contents/runtime/Contents/Home/bin/java >> ? >> >> CFBundleIdentifier >> net.java.openjdk.java >> ? >> >> >> >> This is an obscure corner case in the macOS bundle story: A standalone tool, like `java`, which isn?t in a bundle structure, and thus can?t have a standalone `Info.plist` file, can put its information property list in a `__TEXT` / `__info_plist` section within its executable. And it seems that the folks who created your Java runtime did just that. >> >> Given that, the Mac App Store error is valid: You are trying to submit an executable whose bundle ID matches some existing app. >> >> To get around this check you?ll need to give `java` a new bundle ID. That?s not easy to do. This `__TEXT` / `__info_plist` section is set up by a linker option (see `-sectcreate` in and there?s no good way to modify it after the fact [1]. I had read this but possibly didn?t grok the issue myself. If I understand correctly now the conflict isn?t within the application but across applications to some other application that has already been added to the Mac App Store that included the commands with the given CFBundleIdentifier. A solution like including a bundle identifier something like net.java.openjdk.MYAPP.java would be possible at packaging time but not at build time. To fix this at build time you would need to generate a name unique to each installed jdk. Including release net.java.openjdk.JDK_RELEASE.java might avoid some conflicts but would still be open to conflict for two applications at the same release. So it can?t be addressed ?before the fact? either. The only thing I am currently thinking of that might work would be include a replaceable part in the identifier. So something like net.java.openjdk.java.XXXXXXXXXXXXXXXXXXXXXX Where jpackage could include something to change the XXXXX?. to a unique application name. If you don?t change the string size you could probably avoid some of the resizing issues Apple DTS mentions. Whether there is a standard Apple tool to do this I don?t know. From magnus.ihse.bursie at oracle.com Thu May 12 11:58:59 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 May 2022 13:58:59 +0200 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com> References: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com> Message-ID: <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com> On 2022-05-12 13:17, Michael Hall wrote: > I had read this but possibly didn?t grok the issue myself. If I > understand correctly now the conflict isn?t within the application but > across applications to some other application that has already been > added to the Mac App Store that included the commands with the given > CFBundleIdentifier. Yes, that is indeed how I also interpret this. Presumably, the very first developer to submit a jpackaged application to App Store (from what I can tell now OpenJDK itself is not present there, which I mistakenly believed before) got everything working without troubles, but blocked all other developers from submitting their apps. > A solution like including a bundle identifier something like > net.java.openjdk.MYAPP.java would be possible at packaging time but > not at build time. > To fix this at build time you would need to generate a name unique to > each installed jdk. Including release > net.java.openjdk.JDK_RELEASE.java might avoid some conflicts but would > still be open to conflict for two applications at the same release. So > it can?t be addressed ?before the fact? either. The only thing I am > currently thinking of that might work would be include a replaceable > part in the identifier. So something like > net.java.openjdk.java.XXXXXXXXXXXXXXXXXXXXXX > Where jpackage could include something to change the XXXXX?. to a > unique application name. If you don?t change the string size you could > probably avoid some of the resizing issues Apple DTS mentions. Whether > there is a standard Apple tool to do this I don?t know. As you say, we're a bit in a bind since the java executable needs to be created when the JDK is built, but the bundle ID needs to be determined when jpackage is run (and a suitable, per-application ID can be created), and there is no standard tooling to update the bundle ID after build time. I believe what you are describing is exactly solution #2 suggested by the Apple engineer. I don't think that would be horribly difficult to achieve, though. Sure, it's a bit of a hack, but not the ugliest I've seen in my days. If we go down this route, I suppose we do something like this: 1) When building the JDK, we create an additional copy of the java executable, and store it with the jdk.jpackage resources. Let's call it java.template, for the sake of it. This is identical to the real bin/java except for the fact that it contains a different bundle ID, with a large enough padding field, like XXXXX...? This way, we don't have to mess around with the real java executable for the JDK. 2) At jpackage time, this java.template file is installed instead of bin/java, and the padding field is replaced by a unique value. The java executable is small (33kB on macOS, currently) so a simple search through the binary field for the pattern is likely to work alright. As long as there are no checksums being broken, this should be straightforward. My primary suggestion would to be to use an UUID for the unique ID. They are of fixed length, are for all intents and purposes unique and you can conjure them up from your hat. (An alternative is that the user needs to specify a unique ID, but that is probably a less ideal solution.) Presumably, we can have some kind of prefix like "org.openjdk.jpackage." before the UUID to make them a bit understandable, if someone where to inspect the package metadata. This seems like a fully workable solution to me. However, I'd really like to understand option #1 better, which was: "Package the `java` executable in a standard bundle, replacing `runtime/Contents/Home/bin/java` with a symlink to that." I don't know what a "standard bundle" is, or how you would go around to package the java executable in one. But on the surface, it sounds much nicer than binary editing. I also don't understand if that means that the standard bundle needs to be created at jpackage time, so it gives us the chance to set a proper ID, or if the standard bundle can be created at build time, and then the existence of this bundle just makes Apple avoid the bundle ID collision checks. Or if I'm just misunderstanding it all... /Magnus From afarley at openjdk.java.net Thu May 12 12:00:48 2022 From: afarley at openjdk.java.net (Adam Farley) Date: Thu, 12 May 2022 12:00:48 GMT Subject: RFR: 8286601: Mac Aarch: Excessive warnings to be ignored for build jdk In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:55:29 GMT, Adam Farley wrote: > These warnings are ignored while building the build+full jdks with gcc, > but only ignored while building the full JDK if using clang. This > produces tons of warnings we normally ignore, e.g. unused parameter. > > I suggest that if we're ignoring this type of error while using gcc, > we should also ignore them while using clang. > > Signed-off-by: Adam Farley Thanks Erik and Magnus. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8665 From mik3hall at gmail.com Thu May 12 12:10:24 2022 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 12 May 2022 07:10:24 -0500 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com> References: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com> <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com> Message-ID: > > My primary suggestion would to be to use an UUID for the unique ID. They are of fixed length, are for all intents and purposes unique and you can conjure them up from your hat. (An alternative is that the user needs to specify a unique ID, but that is probably a less ideal solution.) Presumably, we can have some kind of prefix like "org.openjdk.jpackage." before the UUID to make them a bit understandable, if someone where to inspect the package metadata.e I was thinking jpackage would change the XXX to app name but a fixed size unique field would probably be better. > > This seems like a fully workable solution to me. However, I'd really like to understand option #1 better, which was: "Package the `java` executable in a standard bundle, replacing `runtime/Contents/Home/bin/java` with a symlink to that." > > I don't know what a "standard bundle" is, or how you would go around to package the java executable in one. But on the surface, it sounds much nicer than binary editing. > > I also don't understand if that means that the standard bundle needs to be created at jpackage time, so it gives us the chance to set a proper ID, or if the standard bundle can be created at build time, and then the existence of this bundle just makes Apple avoid the bundle ID collision checks. Or if I'm just misunderstanding it all... > > /Magnus I may again not understanding but I was thinking they were talking about something like symlinks to a machine installed JDK and this seemed to me to defeat some of the purpose of embedding the jdk. But he could be thinking else. Something external to the application anyhow it seemed. From erikj at openjdk.java.net Thu May 12 12:44:52 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 12 May 2022 12:44:52 GMT Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64 In-Reply-To: References: Message-ID: <-hqvmnHiJUolmAt5JCObYbHwkCGOmwdGNMTRhc1JPAU=.aed971e3-7581-4de7-b14f-6a358e08e98e@github.com> On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. > We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8675 From erik.joelsson at oracle.com Thu May 12 13:25:35 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 12 May 2022 06:25:35 -0700 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com> References: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com> <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com> Message-ID: On 2022-05-12 04:58, Magnus Ihse Bursie wrote: > On 2022-05-12 13:17, Michael Hall wrote: >> A solution like including a bundle identifier something like >> net.java.openjdk.MYAPP.java would be possible at packaging time but >> not at build time. >> To fix this at build time you would need to generate a name unique to >> each installed jdk. Including release >> net.java.openjdk.JDK_RELEASE.java might avoid some conflicts but >> would still be open to conflict for two applications at the same >> release. So it can?t be addressed ?before the fact? either. The only >> thing I am currently thinking of that might work would be include a >> replaceable part in the identifier. So something like >> net.java.openjdk.java.XXXXXXXXXXXXXXXXXXXXXX >> Where jpackage could include something to change the XXXXX?. to a >> unique application name. If you don?t change the string size you >> could probably avoid some of the resizing issues Apple DTS mentions. >> Whether there is a standard Apple tool to do this I don?t know. > > As you say, we're a bit in a bind since the java executable needs to > be created when the JDK is built, but the bundle ID needs to be > determined when jpackage is run (and a suitable, per-application ID > can be created), and there is no standard tooling to update the bundle > ID after build time. > > I believe what you are describing is exactly solution #2 suggested by > the Apple engineer. I don't think that would be horribly difficult to > achieve, though. Sure, it's a bit of a hack, but not the ugliest I've > seen in my days. If we go down this route, I suppose we do something > like this: > > 1) When building the JDK, we create an additional copy of the java > executable, and store it with the jdk.jpackage resources. Let's call > it java.template, for the sake of it. This is identical to the real > bin/java except for the fact that it contains a different bundle ID, > with a large enough padding field, like XXXXX...? This way, we don't > have to mess around with the real java executable for the JDK. Aren't we embedding this bundle ID in every launcher, so you would need a .template for each possible launcher that could be included in an app? What I think we need to do is first evaluate if we actually need to embed this bundle ID in the executables at all, or rather, what would the consequences be if we didn't. My understanding is that we only do this to be able to run them outside of a bundle directory structure, but this would need some pretty thorough testing of course. If we are to generate a special set of launchers for jpackage, maybe all we need to do is not embed any bundle ID in them, as they are meant to only be used within a jpackaged app, so they should be covered by Info.plist files anyway. /Erik From swpalmer at gmail.com Thu May 12 13:34:19 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 12 May 2022 09:34:19 -0400 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: References: Message-ID: <88CD901E-5E0F-4400-96E0-4094AAB62C95@gmail.com> > On May 12, 2022, at 8:10 AM, Michael Hall wrote: > > ? > >> >> My primary suggestion would to be to use an UUID for the unique ID. They are of fixed length, are for all intents and purposes unique and you can conjure them up from your hat. (An alternative is that the user needs to specify a unique ID, but that is probably a less ideal solution.) Presumably, we can have some kind of prefix like "org.openjdk.jpackage." before the UUID to make them a bit understandable, if someone where to inspect the package metadata.e > > I was thinking jpackage would change the XXX to app name but a fixed size unique field would probably be better. >> >> This seems like a fully workable solution to me. However, I'd really like to understand option #1 better, which was: "Package the `java` executable in a standard bundle, replacing `runtime/Contents/Home/bin/java` with a symlink to that." >> >> I don't know what a "standard bundle" is, or how you would go around to package the java executable in one. But on the surface, it sounds much nicer than binary editing. >> >> I also don't understand if that means that the standard bundle needs to be created at jpackage time, so it gives us the chance to set a proper ID, or if the standard bundle can be created at build time, and then the existence of this bundle just makes Apple avoid the bundle ID collision checks. Or if I'm just misunderstanding it all... >> >> /Magnus > > I may again not understanding but I was thinking they were talking about something like symlinks to a machine installed JDK and this seemed to me to defeat some of the purpose of embedding the jdk. But he could be thinking else. Something external to the application anyhow it seemed. > I thought they meant something like the embedded JDK would be like a framework bundle. Since the framework is expected to be the same in multiple apps it would be excluded from the duplicate id check. (I think that is related to the older bug that the Apple guy thought might have come back.) Scott From mcimadamore at openjdk.java.net Thu May 12 15:45:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 15:45:01 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: - Merge branch 'master' into foreign-preview - Merge branch 'master' into foreign-preview - Fix crashes in heap segment benchmarks due to misaligned access - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=44 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu May 12 15:51:00 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 15:51:00 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 08:29:52 GMT, Guoxiong Li wrote: >>> Remind: please use the command `/jep JEP-424` [1] to mark this PR. >>> >>> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep >> >> Question: I'm willing to try it out. If something goes wrong - would a `jep unneeded` be enough to "unstuck" this PR? > >> would a jep unneeded be enough to "unstuck" this PR? > > Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep command. @lgxbslgx - JEP has been targeted, but the JEP action seems to be blocking this - what should we do? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu May 12 16:21:59 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 16:21:59 GMT Subject: Integrated: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 This pull request has now been integrated. Changeset: 2c5d1362 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/2c5d136260fa717afa374db8b923b7c886d069b7 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod 8282191: Implementation of Foreign Function & Memory API (Preview) Reviewed-by: erikj, jvernee, psandoz, dholmes, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From asemenyuk at openjdk.java.net Thu May 12 17:34:44 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 12 May 2022 17:34:44 GMT Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2] In-Reply-To: References: Message-ID: <6w_XCI-RPohWecEn7OmAIgEJ-fDz1s3fAoVerdZr_js=.374070ee-c1c6-4455-81a2-09a07441ad87@github.com> On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev wrote: >> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible. >> - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles. >> - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error. >> - Added two tests to validate fix. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2] Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8666 From magnus.ihse.bursie at oracle.com Thu May 12 18:18:10 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 May 2022 20:18:10 +0200 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: References: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com> <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com> Message-ID: <954a1c56-3cc5-a890-aec9-b9af2ab39d24@oracle.com> > Aren't we embedding this bundle ID in every launcher, so you would > need a .template for each possible launcher that could be > included in an app? I naively assumed that only the java launcher was needed, since this is about packaging a Java app, so all you'd need is an entry to your main class. Is this not the case? > > What I think we need to do is first evaluate if we actually need to > embed this bundle ID in the executables at all, or rather, what would > the consequences be if we didn't. My understanding is that we only do > this to be able to run them outside of a bundle directory structure, > but this would need some pretty thorough testing of course. If we are > to generate a special set of launchers for jpackage, maybe all we need > to do is not embed any bundle ID in them, as they are meant to only be > used within a jpackaged app, so they should be covered by Info.plist > files anyway. What you say sounds good, although I feel I only partially understand it. :-) I assume the important point here is that the app get the NSMicrophoneUsageDescription property, and afaict this can be provided by the Info.plist file for the entire application, as you say. And possible the problem here is that we embed metadata in the java executable at the same time. There seems to be a lot of guessing here. :-) I assume we either need to read up on how this works (which might be difficult if this is seem as a badly documented corner case even by Apple tech support), or test some alternatives, or perhaps both. That solution make take some time to get correct, so the jpackage team needs to decide if they want to go with the workaround in this PR in the meantime. /Magnus > > /Erik From kbarrett at openjdk.java.net Thu May 12 18:31:49 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 12 May 2022 18:31:49 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Calculate char offset before realloc() > > Thanks for all to review this PR! I think we should separate this issue as following: > > * Suppress warnings > * make/modules/java.desktop/lib/Awt2dLibraries.gmk > * src/hotspot/share/classfile/bytecodeAssembler.cpp > * src/hotspot/share/classfile/classFileParser.cpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > * src/hotspot/share/opto/memnode.cpp > * src/hotspot/share/opto/type.cpp > * src/hotspot/share/utilities/compilerWarnings.hpp > * src/hotspot/share/utilities/compilerWarnings_gcc.hpp > * src/java.base/unix/native/libjli/java_md_common.c > * Bug fixes > * src/java.base/share/native/libjli/java.c > * src/java.base/share/native/libjli/parse_manifest.c > * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c > > I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. > > I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > @YaSuenag From my PoV this sounds like a good suggestion. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From mik3hall at gmail.com Thu May 12 18:56:55 2022 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 12 May 2022 13:56:55 -0500 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: <954a1c56-3cc5-a890-aec9-b9af2ab39d24@oracle.com> References: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com> <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com> <954a1c56-3cc5-a890-aec9-b9af2ab39d24@oracle.com> Message-ID: <83521295-A5C2-47F7-9908-BFDD449C89DF@gmail.com> > > What you say sounds good, although I feel I only partially understand it. :-) If it?s correct that normal applications don?t need the executable included Info.plist and jpackage can somehow get versions that don?t include it that seems the easiest and most hack free solution. Apple DTS did suggest including it might avoid some TCC check but I don?t know what that might be about. I don?t know how many apps try to include native commands but I have at least one non-App Store one that does. An attempt at a solution seems worthwhile rather just throwing errors when a developer tries to get theirs into the App Store. > > I assume the important point here is that the app get the NSMicrophoneUsageDescription property, and afaict this can be provided by the Info.plist file for the entire application, as you say. And possible the problem here is that we embed metadata in the java executable at the same time. > Uh, this is something I again don?t understand. It seems questionable that most java applications would need this Info.plist key granting access to the microphone. https://developer.apple.com/documentation/bundleresources/information_property_list/nsmicrophoneusagedescription It should be up to the developer to include this in their application Info.plist if their application requires it. That is where I thought my earlier suggestion of allowing application post-processing before standalone signing would make sense. The current jpackage solution of allowing the developer to include a separate complete alternate Info.plist in a separate directory I found somewhat awkward. With post-processing you could include a tool like PlistBuddy https://www.unix.com/man-page/osx/8/PLISTBUDDY/ To script the Info.plist changes. I believe this is used by native OS/X applications for this purpose including from XCode. I think it is actually an Apple tool. With a funner name than usual for them. > There seems to be a lot of guessing here. :-) I assume we either need to read up on how this works (which might be difficult if this is seem as a badly documented corner case even by Apple tech support), or test some alternatives, or perhaps both. > > That solution make take some time to get correct, so the jpackage team needs to decide if they want to go with the workaround in this PR in the meantime. > OK, one last possible misunderstanding on my part. The PR simply throws an error if commands are included. It doesn?t involve a workaround does it? From mik3hall at gmail.com Thu May 12 19:03:31 2022 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 12 May 2022 14:03:31 -0500 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: <83521295-A5C2-47F7-9908-BFDD449C89DF@gmail.com> References: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com> <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com> <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com> <954a1c56-3cc5-a890-aec9-b9af2ab39d24@oracle.com> <83521295-A5C2-47F7-9908-BFDD449C89DF@gmail.com> Message-ID: <179A72E9-ACEC-4CCF-B1A5-EB1A567A22A7@gmail.com> > What you say sounds good, although I feel I only partially understand it. :-) If it?s correct that normal applications don?t need the executable included Info.plist and jpackage can somehow get versions that don?t include it that seems the easiest and most hack free solution. Apple DTS did suggest including it might avoid some TCC check but I don?t know what that might be about. I don?t know how many apps try to include native commands but I have at least one non-App Store one that does. An attempt at a solution seems worthwhile rather than just throwing errors when a developer tries to get theirs into the App Store. > I assume the important point here is that the app get the NSMicrophoneUsageDescription property, and afaict this can be provided by the Info.plist file for the entire application, as you say. And possible the problem here is that we embed metadata in the java executable at the same time. Uh, this is something I again don?t understand. It seems questionable that most java applications would need this Info.plist key granting access to the microphone. https://developer.apple.com/documentation/bundleresources/information_property_list/nsmicrophoneusagedescription It should be up to the developer to include this in their application Info.plist if their application requires it. That is where I thought my earlier suggestion of allowing application post-processing before doing separate standalone signing would make sense. The current jpackage solution of allowing the developer to include a separate complete alternate Info.plist in a separate directory I found somewhat awkward. With post-processing you could include a tool like PlistBuddy https://www.unix.com/man-page/osx/8/PLISTBUDDY/ To script the Info.plist changes. I believe this is used by native OS/X applications for this purpose including from XCode. I think it is actually an Apple tool. With a funner name than usual for them. > There seems to be a lot of guessing here. :-) I assume we either need to read up on how this works (which might be difficult if this is seem as a badly documented corner case even by Apple tech support), or test some alternatives, or perhaps both. > > That solution make take some time to get correct, so the jpackage team needs to decide if they want to go with the workaround in this PR in the meantime. OK, one last possible misunderstanding on my part. The PR simply throws an error if commands are included. It doesn?t involve a workaround does it? From prr at openjdk.java.net Thu May 12 19:10:51 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 12 May 2022 19:10:51 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Calculate char offset before realloc() I will see what upstream thinks about the harfbuzz warning but in the mean time we can just disable it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ihse at openjdk.java.net Thu May 12 20:13:48 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 12 May 2022 20:13:48 GMT Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev wrote: >> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible. >> - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles. >> - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error. >> - Added two tests to validate fix. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2] We have the `NSMicrophoneUsageDescription` permission on the `java` launcher in the JDK, since otherwise no Java program can access the mike, even though most won't care. I agree that the situation is different for a jpackaged app, where the developer knows if that permission is needed or not. Yes, plistbuddy is an official Apple program. My understanding of the PR was that native commands are removed by jlink if the user is packaging on a mac for the App Store. I thought this was a workaround that solved the immediate problem of not being able to submit the app to App Store. (However, I don't know how the app is supposed to be started without a launcher...) ------------- PR: https://git.openjdk.java.net/jdk/pull/8666 From mik3hall at gmail.com Thu May 12 20:58:18 2022 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 12 May 2022 15:58:18 -0500 Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2] In-Reply-To: References: Message-ID: > On May 12, 2022, at 3:13 PM, Magnus Ihse Bursie wrote: > > On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev wrote: > >>> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible. >>> - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles. >>> - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error. >>> - Added two tests to validate fix. >> >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2] > > We have the `NSMicrophoneUsageDescription` permission on the `java` launcher in the JDK, since otherwise no Java program can access the mike, even though most won't care. I agree that the situation is different for a jpackaged app, where the developer knows if that permission is needed or not. I?d have to agree with Apple DTS that this is an interesting exception. > > Yes, plistbuddy is an official Apple program. > > My understanding of the PR was that native commands are removed by jlink if the user is packaging on a mac for the App Store. I thought this was a workaround that solved the immediate problem of not being able to submit the app to App Store. (However, I don't know how the app is supposed to be started without a launcher?) > I thought that if the app was indicated as intended for the App Store and native commands were also indicated an error would be thrown and the app not built. It doesn?t allow apps that will fail to attempt the App Store but does nothing for getting them there. Switching from an error to a warning and forcing the native commands to be stripped would allow the app into the app store but with unknown functionality probably not working. My understanding. From asemenyuk at openjdk.java.net Thu May 12 23:39:44 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 12 May 2022 23:39:44 GMT Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: References: Message-ID: <8KF1pLYghl_meLa6EP_pfVbtb7h-V2oMs9QtOBdMHd0=.396e291a-5139-4bc6-9e7a-44146e714dd8@github.com> On Thu, 12 May 2022 20:59:53 GMT, Michael Hall wrote: > However, I don't know how the app is supposed to be started without a launcher... jpackage supplies an alternative launcher that doesn't have plist. ------------- PR: https://git.openjdk.java.net/jdk/pull/8666 From jpai at openjdk.java.net Fri May 13 01:59:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 01:59:50 GMT Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64 In-Reply-To: References: Message-ID: On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. > We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64. Thank you everyone for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8675 From jpai at openjdk.java.net Fri May 13 01:59:51 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 01:59:51 GMT Subject: Integrated: 8286623: Bundle zlib by default with JDK on macos aarch64 In-Reply-To: References: Message-ID: On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. > We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64. This pull request has now been integrated. Changeset: c3bade2e Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/c3bade2e08f865bf1e65d48e6d27bff9c022d35f Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod 8286623: Bundle zlib by default with JDK on macos aarch64 Reviewed-by: lancea, ihse, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8675 From asotona at openjdk.java.net Fri May 13 08:32:29 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Fri, 13 May 2022 08:32:29 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v6] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base new case appeared in java.base by moving jdk.incubator.foreign code under java.base - Merge remote-tracking branch 'upstream/master' into JDK-8244681 # Conflicts: # make/test/BuildMicrobenchmark.gmk - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments jdk.internal.le make patch to disable warnings - 8244681: Add a warning for possibly lossy conversion in compound assignments ------------- Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=05 Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From uschindler at openjdk.java.net Fri May 13 08:37:17 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 08:37:17 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 15:45:01 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: > > - Merge branch 'master' into foreign-preview > - Merge branch 'master' into foreign-preview > - Fix crashes in heap segment benchmarks due to misaligned access > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Add tests for loaderLookup/restricted method corner cases > - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI > * Tweak restricted method check to work when there's no caller class > - Tweak examples in SymbolLookup javadoc > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b Some late comments and suggestions to fix inconsistencies and wrong javadocs. src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: > 1043: * > 1044: * @throws UnsupportedOperationException > 1045: * If an unsupported map mode is specified. I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. As this is already merged, should I open a PR fixing the docs or open an issue? src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: > 1162: } > 1163: if (unmapper != null) { > 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: - New code returning `MemorySegment` uses `unmapper.address()` - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) Should I open an issue or a PR to fix this (because this is already merged)? See the mailing list posts: - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 08:37:18 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 08:37:18 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 08:25:01 GMT, Uwe Schindler wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Merge branch 'master' into foreign-preview >> - Merge branch 'master' into foreign-preview >> - Fix crashes in heap segment benchmarks due to misaligned access >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Add tests for loaderLookup/restricted method corner cases >> - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class >> - Tweak examples in SymbolLookup javadoc >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: > >> 1043: * >> 1044: * @throws UnsupportedOperationException >> 1045: * If an unsupported map mode is specified. > > I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. > > As this is already merged, should I open a PR fixing the docs or open an issue? This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Fri May 13 08:53:04 2022 From: duke at openjdk.java.net (limck599) Date: Fri, 13 May 2022 08:53:04 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - Merge branch 'master' into JDK-8242181 > - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 Marked as reviewed by limck599 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From chagedorn at openjdk.java.net Fri May 13 08:53:06 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 13 May 2022 08:53:06 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:34:03 GMT, Magnus Ihse Bursie wrote: >> make/autoconf/flags-cflags.m4 line 116: >> >>> 114: fi >>> 115: >>> 116: CFLAGS_DEBUG_SYMBOLS="-g -gdwarf-4" >> >> We may need to guard this with a FLAGS_COMPILER_CHECK_ARGUMENTS. Perhaps it should also be applied only on Linux since the whole feature is Linux only. What do you think @magicus? > > I'm googling around for some information about -gdwarf-4 but is mostly coming up empty handed. :( I found [this](https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-DWARF-5-Possible-Default) saying that dwarf-5 became default in gcc11. It also claims dwarf-4 is about 10 years old. My guess is that all our supported gcc versions do support -gdwarf-4, but this needs to be verified. > > In practice, we only use gcc on linux so I'm not convinced we need to have an addition check for that. If we ever are going to support gcc on other OSes I think we'll have many more, much harder problems, than to remove the -gdwarf-4 flag. I'm back to work again. I also had a look but could not find something on Google, either. I then skimmed through the old GCC manuals. I found the first occurrence of `-gdwarf-4` in the manual for GCC 4.5.4 [here](https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc.pdf): - gdwarf-version Produce debugging information in DWARF format (if that is supported). This is the format used by DBX on IRIX 6. The value of version may be either 2, 3 or 4; the default version is 2. While the manual for GCC 4.4.7 only mentions `-gdwarf-2`: -gdwarf-2 Produce debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on IRIX 6. With this option, GCC uses features of DWARF version 3 when they are useful; version 3 is upward compatible with version 2, but may still cause problems for older debuggers. The minimum accepted GCC version is currently 5.0 according to: https://github.com/openjdk/jdk/blob/d5ae3833b1b71eb84fadb69c0c92851400f8921c/doc/building.md?plain=1#L341-L344 This suggests that all our supported GCC versions should accept `-gdwarf-4`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From mcimadamore at openjdk.java.net Fri May 13 09:48:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 09:48:02 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 08:33:11 GMT, Uwe Schindler wrote: >> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: >> >>> 1043: * >>> 1044: * @throws UnsupportedOperationException >>> 1045: * If an unsupported map mode is specified. >> >> I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. >> >> As this is already merged, should I open a PR fixing the docs or open an issue? > > This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) @uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 13 09:48:08 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 09:48:08 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> On Fri, 13 May 2022 08:29:13 GMT, Uwe Schindler wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Merge branch 'master' into foreign-preview >> - Merge branch 'master' into foreign-preview >> - Fix crashes in heap segment benchmarks due to misaligned access >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Add tests for loaderLookup/restricted method corner cases >> - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class >> - Tweak examples in SymbolLookup javadoc >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: > >> 1162: } >> 1163: if (unmapper != null) { >> 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, > > When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: > - New code returning `MemorySegment` uses `unmapper.address()` > - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) > > Should I open an issue or a PR to fix this (because this is already merged)? > > See the mailing list posts: > - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html > - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From ysuenaga at openjdk.java.net Fri May 13 10:02:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 13 May 2022 10:02:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Revert change for java.c , parse_manifest.c , LinuxPackage.c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/b3afa3e0..d5ef2c63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=03-04 Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ihse at openjdk.java.net Fri May 13 10:07:27 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 10:07:27 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - Merge branch 'master' into JDK-8242181 > - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7126 From ihse at openjdk.java.net Fri May 13 10:07:29 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 10:07:29 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 08:43:35 GMT, Christian Hagedorn wrote: >> I'm googling around for some information about -gdwarf-4 but is mostly coming up empty handed. :( I found [this](https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-DWARF-5-Possible-Default) saying that dwarf-5 became default in gcc11. It also claims dwarf-4 is about 10 years old. My guess is that all our supported gcc versions do support -gdwarf-4, but this needs to be verified. >> >> In practice, we only use gcc on linux so I'm not convinced we need to have an addition check for that. If we ever are going to support gcc on other OSes I think we'll have many more, much harder problems, than to remove the -gdwarf-4 flag. > > I'm back to work again. I also had a look but could not find something on Google, either. I then skimmed through the old GCC manuals. I found the first occurrence of `-gdwarf-4` in the manual for GCC 4.5.4 [here](https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc.pdf): > > > - gdwarf-version > Produce debugging information in DWARF format (if that is supported). This > is the format used by DBX on IRIX 6. The value of version may be either 2, 3 > or 4; the default version is 2. > > While the manual for GCC 4.4.7 only mentions `-gdwarf-2`: > > -gdwarf-2 > Produce debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on > IRIX 6. With this option, GCC > uses features of DWARF version 3 when they are useful; version 3 is upward > compatible with version 2, but may still cause problems for older debuggers. > > > The minimum accepted GCC version is currently 5.0 according to: > https://github.com/openjdk/jdk/blob/d5ae3833b1b71eb84fadb69c0c92851400f8921c/doc/building.md?plain=1#L341-L344 > > This suggests that all our supported GCC versions should accept `-gdwarf-4`. @chhagedorn Thanks for the research. You provide more than necessary reason to accept `-gdwarf-4` without any further checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From uschindler at openjdk.java.net Fri May 13 11:06:12 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 11:06:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> Message-ID: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> On Fri, 13 May 2022 09:43:55 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: >> >>> 1162: } >>> 1163: if (unmapper != null) { >>> 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, >> >> When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: >> - New code returning `MemorySegment` uses `unmapper.address()` >> - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) >> >> Should I open an issue or a PR to fix this (because this is already merged)? >> >> See the mailing list posts: >> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html >> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html > > Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code. RFE = issue? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 13 12:03:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 12:03:01 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> Message-ID: On Fri, 13 May 2022 11:01:09 GMT, Uwe Schindler wrote: > RFE = issue? issue, with type RFE (request for enhancement) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 12:19:15 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 12:19:15 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> Message-ID: On Fri, 13 May 2022 11:59:12 GMT, Maurizio Cimadamore wrote: >> RFE = issue? > >> RFE = issue? > > issue, with type RFE (request for enhancement) See: https://bugs.openjdk.java.net/browse/JDK-8286734 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 12:29:09 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 12:29:09 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: <_qJfbHWbWDSXgHQx9PRP2YDQ7cLkC41BmxL_osQIRhs=.dd01fb6e-e671-4bb4-8332-9c9d337abaf9@github.com> On Fri, 13 May 2022 09:42:44 GMT, Maurizio Cimadamore wrote: >> This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) > > @uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue. See https://bugs.openjdk.java.net/browse/JDK-8286735 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From ysuenaga at openjdk.java.net Fri May 13 14:17:44 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 13 May 2022 14:17:44 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c I've sent another review request for bug fixes as #8694 and #8696 , and I reverted change for them from this PR. Could you review this PR to suppress warnings which we can ignore? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jpai at openjdk.java.net Fri May 13 14:39:44 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 14:39:44 GMT Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2] In-Reply-To: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> Message-ID: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> > Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS? > > As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command. > > Tested locally on macOS by running: > > > cd test/failure_handler > make clean > make test > > Then checked the generated environment.html files for the dmesg command output. Looks fine after this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8703/files - new: https://git.openjdk.java.net/jdk/pull/8703/files/db538083..f85acab5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8703&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8703&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8703/head:pull/8703 PR: https://git.openjdk.java.net/jdk/pull/8703 From dfuchs at openjdk.java.net Fri May 13 14:39:44 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 13 May 2022 14:39:44 GMT Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2] In-Reply-To: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> Message-ID: On Fri, 13 May 2022 14:36:02 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS? >> >> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command. >> >> Tested locally on macOS by running: >> >> >> cd test/failure_handler >> make clean >> make test >> >> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > copyright year LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8703 From naoto at openjdk.java.net Fri May 13 17:13:14 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 13 May 2022 17:13:14 GMT Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools Message-ID: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch. ------------- Commit messages: - 8286399: Address possibly lossy conversions in JDK Build Tools Changes: https://git.openjdk.java.net/jdk/pull/8706/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8706&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286399 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8706.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8706/head:pull/8706 PR: https://git.openjdk.java.net/jdk/pull/8706 From rriggs at openjdk.java.net Fri May 13 17:22:50 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 13 May 2022 17:22:50 GMT Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools In-Reply-To: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> Message-ID: <78raR4MgM0oU5wO6qNbEDCWXDOzqnvewaglma5odWNw=.231c3b94-aaa6-4662-8174-9f849ec6a23c@github.com> On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato wrote: > Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8706 From lancea at openjdk.java.net Fri May 13 17:46:47 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 13 May 2022 17:46:47 GMT Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2] In-Reply-To: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> Message-ID: On Fri, 13 May 2022 14:39:44 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS? >> >> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command. >> >> Tested locally on macOS by running: >> >> >> cd test/failure_handler >> make clean >> make test >> >> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > copyright year looks ok to me ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8703 From joehw at openjdk.java.net Fri May 13 22:14:50 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 13 May 2022 22:14:50 GMT Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools In-Reply-To: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> Message-ID: On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato wrote: > Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch. make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java line 1278: > 1276: state[numCategories] |= (short) END_STATE_FLAG; > 1277: if (sawEarlyBreak) { > 1278: state[numCategories] |= LOOKAHEAD_STATE_FLAG; Does this need a cast as well? and also other cases, e.g. line 1019: state[numCategories] = DONT_LOOP_FLAG;? ------------- PR: https://git.openjdk.java.net/jdk/pull/8706 From naoto at openjdk.java.net Fri May 13 22:33:42 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 13 May 2022 22:33:42 GMT Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools In-Reply-To: References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> Message-ID: On Fri, 13 May 2022 22:11:17 GMT, Joe Wang wrote: >> Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch. > > make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java line 1278: > >> 1276: state[numCategories] |= (short) END_STATE_FLAG; >> 1277: if (sawEarlyBreak) { >> 1278: state[numCategories] |= LOOKAHEAD_STATE_FLAG; > > Does this need a cast as well? and also other cases, e.g. line 1019: state[numCategories] = DONT_LOOP_FLAG;? No, it doesn't. `LOOKAHEAD_STATE_FLAG` is defined as `0x2000` which is within the range of `short`. OTOH, `END_STATE_FLAG` is `0x8000` thus a lossy conversion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8706 From joehw at openjdk.java.net Fri May 13 23:45:37 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 13 May 2022 23:45:37 GMT Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools In-Reply-To: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> Message-ID: On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato wrote: > Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8706 From kbarrett at openjdk.java.net Sun May 15 21:00:09 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 15 May 2022 21:00:09 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression Message-ID: Please review this cleanup of deprecation warning suppression when building for Windows. This change consists of several parts. (1) Remove the global deprecation warning suppression when building HotSpot for Windows. (2) Add macro definitions requesting suppression of selected sets of deprecation warnings when building HotSpot for Windows. (3) Remove unnecessary forwarding macros for various POSIX functions in globalDefinitions_visCPP.hpp. These were provided to avoid deprecation warnings (that were previously also being suppressed by the global request). They are now covered by the new macros provided by change (2) above. An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item (2)) and either retain the forwarding macros or define os:: wrapper functions for all of the affected functions. We might eventually do the latter because of other reasons for avoiding some of these functions, but the approach being taken here is simpler. For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 Similarly for _CRT_SECURE_NO_WARNINGS. Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find any documentation for the latter). But it might be better to not supress the warnings and instead use the alternatives (JDK-8286781). Testing: mach5 tier1 ------------- Commit messages: - cleanup Windows deprecation warning suppression Changes: https://git.openjdk.java.net/jdk/pull/8718/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8718&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286262 Stats: 21 lines in 4 files changed: 2 ins; 13 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8718.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8718/head:pull/8718 PR: https://git.openjdk.java.net/jdk/pull/8718 From chagedorn at openjdk.java.net Mon May 16 07:18:12 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 16 May 2022 07:18:12 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:04:25 GMT, Magnus Ihse Bursie wrote: >> I'm back to work again. I also had a look but could not find something on Google, either. I then skimmed through the old GCC manuals. I found the first occurrence of `-gdwarf-4` in the manual for GCC 4.5.4 [here](https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc.pdf): >> >> >> - gdwarf-version >> Produce debugging information in DWARF format (if that is supported). This >> is the format used by DBX on IRIX 6. The value of version may be either 2, 3 >> or 4; the default version is 2. >> >> While the manual for GCC 4.4.7 only mentions `-gdwarf-2`: >> >> -gdwarf-2 >> Produce debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on >> IRIX 6. With this option, GCC >> uses features of DWARF version 3 when they are useful; version 3 is upward >> compatible with version 2, but may still cause problems for older debuggers. >> >> >> The minimum accepted GCC version is currently 5.0 according to: >> https://github.com/openjdk/jdk/blob/d5ae3833b1b71eb84fadb69c0c92851400f8921c/doc/building.md?plain=1#L341-L344 >> >> This suggests that all our supported GCC versions should accept `-gdwarf-4`. > > @chhagedorn Thanks for the research. You provide more than necessary reason to accept `-gdwarf-4` without any further checks. Great, thanks for confirming this and reviewing the build changes! ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From jpai at openjdk.java.net Mon May 16 07:57:54 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 16 May 2022 07:57:54 GMT Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2] In-Reply-To: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> Message-ID: On Fri, 13 May 2022 14:39:44 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS? >> >> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command. >> >> Tested locally on macOS by running: >> >> >> cd test/failure_handler >> make clean >> make test >> >> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > copyright year Thank you Daniel and Lance for the reviews. Would anyone from the build team provide any additional reviews? ------------- PR: https://git.openjdk.java.net/jdk/pull/8703 From mgronlun at openjdk.java.net Mon May 16 10:25:28 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 16 May 2022 10:25:28 GMT Subject: RFR: 8280844: Epoch shift synchronization point for Compiler threads is inadequate Message-ID: Greetings, [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate. The epoch race is avoided only by performing the transition to _thread_in_vm. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8280844 Changes: https://git.openjdk.java.net/jdk/pull/8724/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8724&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280844 Stats: 102 lines in 6 files changed: 14 ins; 84 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8724/head:pull/8724 PR: https://git.openjdk.java.net/jdk/pull/8724 From dholmes at openjdk.java.net Mon May 16 11:28:02 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 16 May 2022 11:28:02 GMT Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2] In-Reply-To: References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> Message-ID: On Mon, 16 May 2022 07:54:09 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright year > > Thank you Daniel and Lance for the reviews. > > Would anyone from the build team like to provide any additional reviews? @jaikiran this is more a SQE issue that an build issue. @lmesnik may have an opinion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8703 From dholmes at openjdk.java.net Mon May 16 11:31:56 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 16 May 2022 11:31:56 GMT Subject: RFR: 8280844: Epoch shift synchronization point for Compiler threads is inadequate In-Reply-To: References: Message-ID: On Mon, 16 May 2022 10:17:42 GMT, Markus Gr?nlund wrote: > Greetings, > > [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate. > > The epoch race is avoided only by performing the transition to _thread_in_vm. > > Testing: jdk_jfr > > Thanks > Markus src/hotspot/share/compiler/compilerEvent.cpp line 126: > 124: static inline void commit(EventType& event) { > 125: JavaThread* thread = JavaThread::current(); > 126: assert(thread->thread_state() == _thread_in_native, "invariant"); You don't need this assert as `ThreadInVMfromNative` already has it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8724 From mgronlun at openjdk.java.net Mon May 16 11:37:43 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 16 May 2022 11:37:43 GMT Subject: RFR: 8280844: Epoch shift synchronization point for Compiler threads is inadequate [v2] In-Reply-To: References: Message-ID: <1e7AHT4Z2EMgm-mxAOrVO0kLCOkjzFpzvh-yL7KNr-I=.42f520bd-25f8-4a0d-9d89-0c238dce9ef1@github.com> > Greetings, > > [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate. > > The epoch race is avoided only by performing the transition to _thread_in_vm. > > Testing: jdk_jfr > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: delegate assertion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8724/files - new: https://git.openjdk.java.net/jdk/pull/8724/files/9ce10130..b4e59b72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8724&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8724&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8724/head:pull/8724 PR: https://git.openjdk.java.net/jdk/pull/8724 From egahlin at openjdk.java.net Mon May 16 13:35:58 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 16 May 2022 13:35:58 GMT Subject: RFR: 8280844: Epoch shift synchronization point for Compiler threads is inadequate [v2] In-Reply-To: <1e7AHT4Z2EMgm-mxAOrVO0kLCOkjzFpzvh-yL7KNr-I=.42f520bd-25f8-4a0d-9d89-0c238dce9ef1@github.com> References: <1e7AHT4Z2EMgm-mxAOrVO0kLCOkjzFpzvh-yL7KNr-I=.42f520bd-25f8-4a0d-9d89-0c238dce9ef1@github.com> Message-ID: On Mon, 16 May 2022 11:37:43 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate. >> >> The epoch race is avoided only by performing the transition to _thread_in_vm. >> >> Testing: jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > delegate assertion Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8724 From asotona at openjdk.java.net Mon May 16 14:45:25 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 16 May 2022 14:45:25 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v7] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'openjdk:master' into JDK-8244681 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base new case appeared in java.base by moving jdk.incubator.foreign code under java.base - Merge remote-tracking branch 'upstream/master' into JDK-8244681 # Conflicts: # make/test/BuildMicrobenchmark.gmk - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments jdk.internal.le make patch to disable warnings - 8244681: Add a warning for possibly lossy conversion in compound assignments ------------- Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06 Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Mon May 16 14:58:33 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 16 May 2022 14:58:33 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v8] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <6fMaRe1U4N-Uz4oe8QKOqIwy-bqkQRVR75XJJpLSXgY=.c8072af3-f0e1-430e-9ab2-33db617c5d77@github.com> > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/a72644e9..74f9f4b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06-07 Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From naoto at openjdk.java.net Mon May 16 15:49:46 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 16 May 2022 15:49:46 GMT Subject: Integrated: 8286399: Address possibly lossy conversions in JDK Build Tools In-Reply-To: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com> Message-ID: <28rLfqfgKslQOUsIr4ss1KOIzvxM5M59rW6o_D_t2H8=.1b45f75e-4a2a-4d2d-b1e9-98fc6425cb33@github.com> On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato wrote: > Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch. This pull request has now been integrated. Changeset: c044cb83 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c044cb8346bb8fbba46db1debe921cf96885ada0 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8286399: Address possibly lossy conversions in JDK Build Tools Reviewed-by: rriggs, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/8706 From ihse at openjdk.java.net Mon May 16 18:34:40 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 16 May 2022 18:34:40 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 Looks good to me, build-wise. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8718 From prr at openjdk.java.net Mon May 16 19:25:45 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 19:25:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From prr at openjdk.java.net Mon May 16 19:25:45 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 19:25:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 00:26:41 GMT, Yasumasa Suenaga wrote: >> I don't understand what the actual warning is getting at .. can anyone explain it ? >> >> FWIW the code is still the same in upstream harfbuzz >> https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc > > I've pasted a part of warning messages to description of this PR, all of messages are here: > > > In function 'void trampoline_reference(hb_trampoline_closure_t*)', > inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*, hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24: So upstream say it is not a problem since the analysis overlooks that it would not reach that free if it were immutable because of a previous check. I guess we disable the false positive warning for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From lmesnik at openjdk.java.net Mon May 16 22:09:33 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 16 May 2022 22:09:33 GMT Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2] In-Reply-To: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> Message-ID: On Fri, 13 May 2022 14:39:44 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS? >> >> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command. >> >> Tested locally on macOS by running: >> >> >> cd test/failure_handler >> make clean >> make test >> >> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > copyright year Looks reasonable. ------------- Marked as reviewed by lmesnik (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8703 From jpai at openjdk.java.net Tue May 17 00:13:46 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 17 May 2022 00:13:46 GMT Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues [v2] In-Reply-To: References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com> Message-ID: On Mon, 16 May 2022 22:06:25 GMT, Leonid Mesnik wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright year > > Looks reasonable. Thank you @lmesnik for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8703 From jpai at openjdk.java.net Tue May 17 00:13:47 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 17 May 2022 00:13:47 GMT Subject: Integrated: 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues In-Reply-To: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com> Message-ID: On Fri, 13 May 2022 14:17:44 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS? > > As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command. > > Tested locally on macOS by running: > > > cd test/failure_handler > make clean > make test > > Then checked the generated environment.html files for the dmesg command output. Looks fine after this change. This pull request has now been integrated. Changeset: 125efe6c Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/125efe6cbaf1e2c263d74a4ada395ac30c479faa Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues Reviewed-by: dfuchs, lancea, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/8703 From ysuenaga at openjdk.java.net Tue May 17 01:28:49 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 01:28:49 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> References: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> Message-ID: On Thu, 12 May 2022 11:02:02 GMT, Magnus Ihse Bursie wrote: >> Thanks for all to review this PR! I think we should separate this issue as following: >> >> * Suppress warnings >> * make/modules/java.desktop/lib/Awt2dLibraries.gmk >> * src/hotspot/share/classfile/bytecodeAssembler.cpp >> * src/hotspot/share/classfile/classFileParser.cpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> * src/hotspot/share/opto/memnode.cpp >> * src/hotspot/share/opto/type.cpp >> * src/hotspot/share/utilities/compilerWarnings.hpp >> * src/hotspot/share/utilities/compilerWarnings_gcc.hpp >> * src/java.base/unix/native/libjli/java_md_common.c >> * Bug fixes >> * src/java.base/share/native/libjli/java.c >> * src/java.base/share/native/libjli/parse_manifest.c >> * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c >> >> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. >> >> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > > @YaSuenag From my PoV this sounds like a good suggestion. @magicus @prrace Thanks for your review! Can I get the review from HotSpot folks? @kimbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Tue May 17 02:20:56 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 02:20:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 18:28:02 GMT, Kim Barrett wrote: >> Thanks for all to review this PR! I think we should separate this issue as following: >> >> * Suppress warnings >> * make/modules/java.desktop/lib/Awt2dLibraries.gmk >> * src/hotspot/share/classfile/bytecodeAssembler.cpp >> * src/hotspot/share/classfile/classFileParser.cpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> * src/hotspot/share/opto/memnode.cpp >> * src/hotspot/share/opto/type.cpp >> * src/hotspot/share/utilities/compilerWarnings.hpp >> * src/hotspot/share/utilities/compilerWarnings_gcc.hpp >> * src/java.base/unix/native/libjli/java_md_common.c >> * Bug fixes >> * src/java.base/share/native/libjli/java.c >> * src/java.base/share/native/libjli/parse_manifest.c >> * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c >> >> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. >> >> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > >> @YaSuenag From my PoV this sounds like a good suggestion. > > +1 > Can I get the review from HotSpot folks? @kimbarrett Already working on it. There are some I don't understand yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Tue May 17 03:19:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 03:19:55 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c Some suggestions for code changes instead of warning suppression. And some warnings that I don't yet understand and don't think should be suppressed without more details or investigation. src/hotspot/share/classfile/bytecodeAssembler.cpp line 95: > 93: ShouldNotReachHere(); > 94: } > 95: PRAGMA_DIAG_POP One of these is another of the symbol_at_put cases that I don't understand. Are there other cases in the switch that warn? And if so, which ones and how? There are no details of this one in the PR cover description. src/hotspot/share/classfile/classFileParser.cpp line 5970: > 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED > 5969: _cp->symbol_at_put(hidden_index, _class_name); > 5970: PRAGMA_DIAG_POP I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: > 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED > 102: *dest = op(bits, *dest); > 103: PRAGMA_DIAG_POP I see no stringop here. I'm still trying to understand what the compiler is complaining about. src/hotspot/share/opto/memnode.cpp line 1413: > 1411: bt == T_BYTE || bt == T_SHORT || > 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); > 1413: PRAGMA_DIAG_POP The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. src/hotspot/share/opto/type.cpp line 4300: > 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED > 4299: fatal("not an element type: %s", type2name(etype)); > 4300: PRAGMA_DIAG_POP Another occurrence of type2name returning NULL for unknown BasicType. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Tue May 17 04:56:00 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 04:56:00 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 03:05:09 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/opto/memnode.cpp line 1413: > >> 1411: bt == T_BYTE || bt == T_SHORT || >> 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); >> 1413: PRAGMA_DIAG_POP > > The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From dholmes at openjdk.java.net Tue May 17 06:33:59 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 May 2022 06:33:59 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 Sorry Kim I'm having trouble seeing what change corresponds to (1) ?? Also the PR talks only about hotspot, but you're changing the JDK flags as well. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8718 From ysuenaga at openjdk.java.net Tue May 17 12:41:16 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 12:41:16 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 01:43:25 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/classfile/classFileParser.cpp line 5970: > >> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED >> 5969: _cp->symbol_at_put(hidden_index, _class_name); >> 5970: PRAGMA_DIAG_POP > > I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) Like the others, it is caused by `Array::at_put()`. In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 12:46:03 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 12:46:03 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 03:02:55 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: > >> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED >> 102: *dest = op(bits, *dest); >> 103: PRAGMA_DIAG_POP > > I see no stringop here. I'm still trying to understand what the compiler is complaining about. I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:15:24 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:15:24 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v6] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Add assert to check the range of BasicType - Merge remote-tracking branch 'upstream/master' into HEAD - Revert change for java.c , parse_manifest.c , LinuxPackage.c - Calculate char offset before realloc() - Use return value from JLI_Snprintf - Avoid pragma error in before GCC 12 - 8286562: GCC 12 reports some compiler warnings ------------- Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=05 Stats: 56 lines in 11 files changed: 46 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:24:50 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:24:50 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <63OHghBxNm4xJxaud2ThDD4e3TN_ENSU4Yeh2wZcqR4=.0bcbd897-c9a3-4e48-9416-47deb17c777e@github.com> On Tue, 17 May 2022 03:14:05 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/classfile/bytecodeAssembler.cpp line 95: > >> 93: ShouldNotReachHere(); >> 94: } >> 95: PRAGMA_DIAG_POP > > One of these is another of the symbol_at_put cases that I don't understand. Are there other cases in the switch that warn? And if so, which ones and how? There are no details of this one in the PR cover description. Most of switch cases are warned. Please see [logs](https://github.com/openjdk/jdk/files/8708578/hotspot_variant-server_libjvm_objs_bytecodeAssembler.o.log) ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:32:42 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v7] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: revert changes for memnode.cpp and type.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/73c306d7..88cbf46d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=05-06 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:32:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:43 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 04:52:44 GMT, Kim Barrett wrote: >> src/hotspot/share/opto/memnode.cpp line 1413: >> >>> 1411: bt == T_BYTE || bt == T_SHORT || >>> 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); >>> 1413: PRAGMA_DIAG_POP >> >> The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. > > While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong. The warning has gone in new commit, and I fixed the comment for `type2name_tab` in it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:32:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <-VtXM4fP_wQp_OWiDuU5FmEvFfDK8Y6_lJ7xHI2doYM=.0a7e6002-9b6a-4bdd-b508-7510fe82230c@github.com> On Tue, 17 May 2022 03:06:49 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/opto/type.cpp line 4300: > >> 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED >> 4299: fatal("not an element type: %s", type2name(etype)); >> 4300: PRAGMA_DIAG_POP > > Another occurrence of type2name returning NULL for unknown BasicType. The warning has gone in new commit due to change of `type2name`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kcr at openjdk.java.net Tue May 17 22:55:44 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 May 2022 22:55:44 GMT Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2] In-Reply-To: References: Message-ID: <0n8TJdsNSrY4EdBkl-kMBH3kw5dxpMmBNESnw5xubD0=.0dbffd09-d82f-42b0-af90-9204d9472e05@github.com> On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev wrote: >> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible. >> - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles. >> - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error. >> - Added two tests to validate fix. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2] I'm just catching up with this thread. Based on the analysis, it's pretty clear that any solution that actually allows bundling native launchers is going to take more research, and is out of scope for this bug. Some combination of [JDK-8286850](https://bugs.openjdk.java.net/browse/JDK-8286850) and/or providing Java launchers that don't have an `Info.plist` is likely needed to provide a complete solution. Given that, I think that this PR seems a reasonable fix to avoid creating an app bundle that can't be uploaded to the app store. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/8666 From aivanov at openjdk.java.net Wed May 18 14:53:28 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 14:53:28 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code Message-ID: Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? It's the last issue in the series, and it still touches different areas of the code. ------------- Commit messages: - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'an? an?' in source code - 8284209: Replace remaining usages of 'a the' in source code - 8284209: Replace remaining usages of 'an the' in source code - ... and 1 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...8290c07e Changes: https://git.openjdk.java.net/jdk/pull/8771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284209 Stats: 51 lines in 41 files changed: 0 ins; 2 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/8771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771 PR: https://git.openjdk.java.net/jdk/pull/8771 From lancea at openjdk.java.net Wed May 18 14:59:56 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 18 May 2022 14:59:56 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8771 From wetmore at openjdk.java.net Wed May 18 15:19:55 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 18 May 2022 15:19:55 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Looked at -java.security.jgss. LGTM ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771 From dfuchs at openjdk.java.net Wed May 18 16:07:52 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 18 May 2022 16:07:52 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Logging/JNDI OK ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771 From iris at openjdk.java.net Wed May 18 17:04:50 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 May 2022 17:04:50 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8771 From dchuyko at openjdk.java.net Wed May 18 19:13:21 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Wed, 18 May 2022 19:13:21 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions Message-ID: On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8282322 - hardlse feature Changes: https://git.openjdk.java.net/jdk/pull/8779/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282322 Stats: 194 lines in 5 files changed: 193 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8779/head:pull/8779 PR: https://git.openjdk.java.net/jdk/pull/8779 From almatvee at openjdk.java.net Wed May 18 20:25:43 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 18 May 2022 20:25:43 GMT Subject: Integrated: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe In-Reply-To: References: Message-ID: On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev wrote: > - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible. > - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles. > - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error. > - Added two tests to validate fix. This pull request has now been integrated. Changeset: b523c884 Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/b523c88480ba5c8f9d78537c9de0abcbf1f867c0 Stats: 221 lines in 7 files changed: 216 ins; 1 del; 4 mod 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe Reviewed-by: asemenyuk, kcr ------------- PR: https://git.openjdk.java.net/jdk/pull/8666 From jjg at openjdk.java.net Wed May 18 22:06:44 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 18 May 2022 22:06:44 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. javac and javadoc changes look OK test/langtools/tools/javac/modules/T8168854/module-info.java line 4: > 2: * @test > 3: * @bug 8168854 > 4: * @summary javac erroneously reject a service interface inner class in a provides clause FYI, this duplication was in the JBS issue summary; now fixed there. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771 From aph at openjdk.java.net Thu May 19 07:43:43 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 07:43:43 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64_lse.S line 57: > 55: .globl aarch64_atomic_xchg_4_default_impl > 56: .align 5 > 57: prfm pstl1strm, [x0] Do we need these `prfm` with LSE instructions? ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 08:02:48 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 08:02:48 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. This looks reasonable enough, but I take it that this would create an OpenJDK build that would not run on AArch64 systems without LSE instructions. Might it not be a better idea to build with outline-atomics, and use them in OpenJDK? That would also solve your problem, and we wouldn't have AArch64 Linux OpenJDK binaries which don't work on all systems. Note that atomic_bsd_aarch64.hpp already does this. I'm also concerned about code rot with options like this one. atomic_linux_aarch64_lse.S would not be tested in any standard configuration. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 08:47:42 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 08:47:42 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Thu, 19 May 2022 07:59:56 GMT, Andrew Haley wrote: > This looks reasonable enough, but I take it that this would create an OpenJDK build that would not run on AArch64 systems without LSE instructions. Forget that, we already do so with extra-cflags. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From ngasson at openjdk.java.net Thu May 19 08:47:42 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 19 May 2022 08:47:42 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. What's the advantage of defining the new hardlse VM feature over using the existing `__ARM_FEATURE_ATOMICS` preprocessor symbol? Both GCC and Clang will define that with an appropriate `-march` value, which you're passing to configure anyway. You could then conditionally emit the LSE instructions in atomic_linux_aarch64.S based on that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 08:54:56 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 08:54:56 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. There is another way to achieve what you want, which is less disruptive and I believe more useful. I just did this: `cp src/hotspot/os_cpu/bsd_aarch64/atomic_bsd_aarch64.hpp src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp` and built OpenJDK with your configury, and it achieves exactly what you want: a HotSpot that uses LSE throughout. If you, therefore, add an option to build with host compiler's atomics, just like BSD does, you'll get what you need with almost no code changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 08:54:59 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 08:54:59 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Thu, 19 May 2022 08:43:55 GMT, Nick Gasson wrote: > What's the advantage of defining the new hardlse VM feature over using the existing `__ARM_FEATURE_ATOMICS` preprocessor symbol? Both GCC and Clang will define that with an appropriate `-march` value, which you're passing to configure anyway. You could then conditionally emit the LSE instructions in atomic_linux_aarch64.S based on that. That's not a bad idea either. In fact, maybe I prefer it to my own suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From dchuyko at openjdk.java.net Thu May 19 10:08:40 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Thu, 19 May 2022 10:08:40 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. Thanks a lot for the great comments. Both suggestions make sense to me. The resulting code can be driven by the compiler flags in the configuration. As I see it: 1. To have a single compile time implementation based on __atomic_add_fetch intrinsics (no .S file at all). 2. In generated part wrap put 'if (UseLSE)' blocks under '#ifdef __ARM_FEATURE_ATOMICS'. Some concerns: 1. It should work at least for Clang and GCC but still will require checking all os-cpu/compiler variants. 2. Windows-aarch64 is the most worrisome. 3. The way of configuration is different for different compilers, not a problem though if we need an optimized build or to make rr work. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 14:39:54 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 14:39:54 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. I literally just tried this: .text #ifdef __ARM_FEATURE_ATOMICS .globl aarch64_atomic_fetch_add_8_default_impl .align 5 aarch64_atomic_fetch_add_8_default_impl: prfm pstl1strm, [x0] 0: ldaddal x1, x2, [x0] dmb ish mov x0, x2 with the obvious `#else` and `#endif` around the non-LSE part and $ objdump -d /home/aph/theRealAph-jdk/build/linux-aarch64-server-slowdebug/hotspot/variant-server/libjvm/objs/atomic_linux_aarch64.o | head -40 ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 14:39:56 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 14:39:56 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Thu, 19 May 2022 10:05:41 GMT, Dmitry Chuyko wrote: > Some concerns: > > 1. It should work at least for Clang and GCC but still will require checking all os-cpu/compiler variants. Really, no. Don't think that way. Just do Linux for now, and throw it over the wall for Windows people. > 3. The way of configuration is different for different compilers, not a problem though if we need an optimized build or to make rr work. See above. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 14:53:49 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 14:53:49 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64_lse.S line 30: > 28: aarch64_atomic_fetch_add_8_default_impl: > 29: prfm pstl1strm, [x0] > 30: 0: ldaddal x1, x2, [x0] Suggestion: ldaddal x1, x2, [x0] You don't need the `0:`label. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 14:57:55 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 14:57:55 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Thu, 19 May 2022 14:36:28 GMT, Andrew Haley wrote: > > Some concerns: > > ``` > > 1. It should work at least for Clang and GCC but still will require checking all os-cpu/compiler variants. Non-Linux systems don't use this stuff at all, so don't worry about it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From kbarrett at openjdk.java.net Thu May 19 16:47:57 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 19 May 2022 16:47:57 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Tue, 17 May 2022 06:30:03 GMT, David Holmes wrote: > Sorry Kim I'm having trouble seeing what change corresponds to (1) ?? The change to CompileJvm.gmk, removing 4996 (deprecation warnings) from the list of disabled warnings. > Also the PR talks only about hotspot, but you're changing the JDK flags as well. ?? I forgot to mention that in addition to reformatting the JDK flags a little bit to be consistent with the JVM flags changes, I also changed -D_CRT_SECURE_NO_DEPRECATE => -D_CRT_SECURE_NO_WARNINGS. Both are (still) supported and have the same meaning, but the latter is the more "modern" (circa VS2005-ish?) spelling. ------------- PR: https://git.openjdk.java.net/jdk/pull/8718 From ihse at openjdk.java.net Fri May 20 08:39:49 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 20 May 2022 08:39:49 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. Configure files need a bit more work. make/autoconf/jvm-features.m4 line 47: > 45: ifdef([custom_jvm_features_valid], custom_jvm_features_valid) \ > 46: \ > 47: cds compiler1 compiler2 dtrace epsilongc g1gc hardlse jfr jni-check \ The feature should be named `hard-lse` to match the `HARD_LSE` define in Hotspot code. (Also, it improves readability.) make/autoconf/jvm-features.m4 line 442: > 440: JVM_FEATURES_VARIANT_FILTER="link-time-opt opt-size" > 441: fi > 442: # Filter out hardlse feature by default You should not set up a PLATFORM filter in `JVM_FEATURES_PREPARE_VARIANT`. In fact, you will need a `JVM_FEATURES_CHECK_HARD_LSE`, which verifies that it can only be enabled on aarch64. See e.g. `JVM_FEATURES_CHECK_JVMCI` foor inspiration on how to write this and where to call it. I suggest you set up `JVM_FEATURES_PLATFORM_FILTER` in that function as well. ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8779 From ihse at openjdk.java.net Fri May 20 08:42:44 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 20 May 2022 08:42:44 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Build changes look good. Thanks for the cleanup! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771 From chagedorn at openjdk.java.net Fri May 20 09:37:03 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 20 May 2022 09:37:03 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v9] In-Reply-To: References: Message-ID: > When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: > > Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f > > This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. > > This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): > > Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) > > For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. > > The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf > I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. > > The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. > > Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. > > **Testing:** > Apart from manual testing, I've added two kinds of tests: > - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. > - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. > > On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. > > To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. > > I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). > > Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! > > Thanks, > Christian Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions - Apply remaining review comments from Thomas Stuefe - Change load_dwarf_file with DwarfFilePath and DebugInfo - Revert renaming on Windows - Merge branch 'master' into JDK-8242181 - Updating some comments - Cleanup loading dwarf file and add summary - Review comments of first pass by Thomas except dwarf file loading - ... and 51 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...5e105465 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7126/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=08 Stats: 2703 lines in 18 files changed: 2606 ins; 41 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/7126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7126/head:pull/7126 PR: https://git.openjdk.java.net/jdk/pull/7126 From chagedorn at openjdk.java.net Fri May 20 09:37:09 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 20 May 2022 09:37:09 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - Merge branch 'master' into JDK-8242181 > - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 I've filed [JDK-8287021](https://bugs.openjdk.java.net/browse/JDK-8287021) to later add support for DWARF 5. To bring up again some general points that are left to decide upon/fix: - UL: If not used, we might want to introduce a special flag like `-XX:TraceDwarf={1,2,3}` to enable/disable different log levels. I'm fine with both approaches. I think we should keep some kind of logging around, especially when later adding DWARF 5 support. > We see test errors on Linux ppcle and x64 in gtests: > > ``` > [ RUN ] os_linux.decoder_get_source_info_valid_vm > /sapmnt/sapjvm_work/openjdk/nb/linuxppc64le/jdk-dev/test/hotspot/gtest/runtime/test_os_linux.cpp:442: Failure > Value of: Decoder::get_source_info(valid_function_pointer, buf, sizeof(buf), &line) > Actual: false > Expected: true > [ FAILED ] os_linux.decoder_get_source_info_valid_vm (93 ms) > [ RUN ] os_linux.decoder_get_source_info_valid_truncated_vm > /sapmnt/sapjvm_work/openjdk/nb/linuxppc64le/jdk-dev/test/hotspot/gtest/runtime/test_os_linux.cpp:454: Failure > Value of: Decoder::get_source_info(valid_function_pointer, buf, 7, &line) > Actual: false > Expected: true > ``` > > We also see Problems in runtime/ErrorHandling and in jfr/jvm/TestDumpOnCrash. Mostly, these tests now have much longer runtimes (about factor 2). With TestDumpOnCrash, both the error file writer and the test itself timeouted on some of our slower machines. @tstuefe: Is this still an issue with the latest commit which added `-gdwarf-4`? I'm currently running some testing with a merge of latest JDK which is looking good so far. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From stuefe at openjdk.java.net Fri May 20 12:53:59 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 20 May 2022 12:53:59 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v6] In-Reply-To: <9x5FYsa0AqHsi17CtUxu5WikmQ9SVrwtF4tdRj7EqoI=.f535f7b3-08a3-46a0-9854-6113f97885d0@github.com> References: <9x5FYsa0AqHsi17CtUxu5WikmQ9SVrwtF4tdRj7EqoI=.f535f7b3-08a3-46a0-9854-6113f97885d0@github.com> Message-ID: <5pMOwxwTtJ8HQPn_VfhzrwLRUxPoTKyvbvMPmJaQXD8=.1d98f182-bef6-4c32-a285-f35c2839a600@github.com> On Sat, 2 Apr 2022 05:54:16 GMT, Thomas Stuefe wrote: >> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: >> >> - Apply remaining review comments from Thomas Stuefe >> - Change load_dwarf_file with DwarfFilePath and DebugInfo >> - Revert renaming on Windows >> - Merge branch 'master' into JDK-8242181 >> - Updating some comments >> - Cleanup loading dwarf file and add summary >> - Review comments of first pass by Thomas except dwarf file loading >> - Merge branch 'master' into JDK-8242181 >> - Make dwarf tag NOT_PRODUCT >> - Change log_* to log_develop_* and log_warning to log_develop_info >> - ... and 48 more: https://git.openjdk.java.net/jdk/compare/c2c0cb2a...06489da2 > > Hi Christian, I won't have time to look at this closely again until end of next week. At first glance it looks a lot better now, thanks for taking my suggestions. > >> Should we generally use assertions inside this error reporting code? For now, I've just went with bailouts without any assertions to avoid a corrupted stack/hs_err_file. > > Assertions will be handled like secondary crashes and show up as "error occurred during error reporting" with, I believe, file/line of the assertion. If that makes sense, that's fine. It helps finding bugs in stack printing code, and if you would crash anyway if you continue, an assertion is ok I think. > > Cheers, Thomas > @tstuefe: Is this still an issue with the latest commit which added -gdwarf-4? Issues seem to have disappeared. I'll schedule some more tests next week to be sure. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From chagedorn at openjdk.java.net Fri May 20 14:57:27 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 20 May 2022 14:57:27 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v9] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 09:37:03 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: > > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - ... and 51 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...5e105465 Thanks Thomas for doing the testing! ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From ysuenaga at openjdk.java.net Sat May 21 13:11:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 21 May 2022 13:11:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v7] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:32:42 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > revert changes for memnode.cpp and type.cpp In case of stringop-overflow errors (bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp) noted that offset of `Array::_data` might be [-2147483648, -1]. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 03:18:48 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 03:18:48 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:38:55 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 5970: >> >>> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED >>> 5969: _cp->symbol_at_put(hidden_index, _class_name); >>> 5970: PRAGMA_DIAG_POP >> >> I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) > > Like the others, it is caused by `Array::at_put()`. > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, > inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ doesn't have flexible array members. The compiler is completely justified in complaining about the apparently out-of-bounds accesses. There is a "well-known" (though moderately ugly) approach to doing flexible array members in C++. Something like this: T* data() { return reinterpret_cast( reinterpret_cast(this) + data_offset()); } where `data_offset()` is new and private: static size_t data_offset() { return offset_of(Array, _data); } Use `data()` everywhere instead of using `_data` directly. There are other places in HotSpot that use this kind of approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 05:03:57 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 05:03:57 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:43:02 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: >> >>> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED >>> 102: *dest = op(bits, *dest); >>> 103: PRAGMA_DIAG_POP >> >> I see no stringop here. I'm still trying to understand what the compiler is complaining about. > > I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: > In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', > inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, > inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, > inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, > inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: I don't think this warning has anything to do with that NULL check. But I'm still not understanding what it is warning about. The "region of size 0" part of the warning message seems important, but I'm not (yet?) seeing how it could be coming up with that. The code involved here is pretty contorted... ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:40:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:40:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge remote-tracking branch 'upstream/master' into gcc12-warnings - Use getter function to access "_data" - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp - revert changes for memnode.cpp and type.cpp - Add assert to check the range of BasicType - Merge remote-tracking branch 'upstream/master' into HEAD - Revert change for java.c , parse_manifest.c , LinuxPackage.c - Calculate char offset before realloc() - Use return value from JLI_Snprintf - Avoid pragma error in before GCC 12 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=07 Stats: 42 lines in 7 files changed: 26 ins; 1 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:40:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:40:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 03:15:20 GMT, Kim Barrett wrote: >> Like the others, it is caused by `Array::at_put()`. >> >> >> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, >> inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: > > `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ > doesn't have flexible array members. The compiler is completely justified in > complaining about the apparently out-of-bounds accesses. > > There is a "well-known" (though moderately ugly) approach to doing flexible > array members in C++. Something like this: > > > T* data() { > return reinterpret_cast( > reinterpret_cast(this) + data_offset()); > } > > > where `data_offset()` is new and private: > > > static size_t data_offset() { > return offset_of(Array, _data); > } > > > Use `data()` everywhere instead of using `_data` directly. > > There are other places in HotSpot that use this kind of approach. Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:48:47 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:48:47 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 05:00:21 GMT, Kim Barrett wrote: >> I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. >> >> >> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: >> In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', >> inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, >> inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, >> inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, >> inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: > > I don't think this warning has anything to do with that NULL check. But I'm > still not understanding what it is warning about. The "region of size 0" part > of the warning message seems important, but I'm not (yet?) seeing how it could > be coming up with that. The code involved here is pretty contorted... It might be GCC bug... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 16:44:58 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 16:44:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <3CBxbI5futoRYrvWQY5-0hUsWNb8fsZWF2goyqFOgY0=.0328a1d2-126e-4f5f-a6d7-ba638499eefd@github.com> On Sun, 22 May 2022 08:35:54 GMT, Yasumasa Suenaga wrote: >> `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ >> doesn't have flexible array members. The compiler is completely justified in >> complaining about the apparently out-of-bounds accesses. >> >> There is a "well-known" (though moderately ugly) approach to doing flexible >> array members in C++. Something like this: >> >> >> T* data() { >> return reinterpret_cast( >> reinterpret_cast(this) + data_offset()); >> } >> >> >> where `data_offset()` is new and private: >> >> >> static size_t data_offset() { >> return offset_of(Array, _data); >> } >> >> >> Use `data()` everywhere instead of using `_data` directly. >> >> There are other places in HotSpot that use this kind of approach. > > Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your suggestion. Good. I see you found and used the existing `base_offset_in_bytes` (which I'd overlooked), rather than using my suggested `data_offset`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 16:48:42 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 16:48:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 08:45:48 GMT, Yasumasa Suenaga wrote: >> I don't think this warning has anything to do with that NULL check. But I'm >> still not understanding what it is warning about. The "region of size 0" part >> of the warning message seems important, but I'm not (yet?) seeing how it could >> be coming up with that. The code involved here is pretty contorted... > > It might be GCC bug... > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 > > This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). I don't see the similarity. That gcc bug is about literals used as addresses, which get treated (suggested inappropriately) as NULL+offset, with NULL+offset being a cause of warnings. I don't see that happening in our case. That is, in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL that I can see. It's hard for me to investigate this any further just by perusing the code, so I'm in the process of getting set up to build with gcc12.x. That will let me do some experiments. It may take me a few days to get to that point though. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From philip.race at oracle.com Sun May 22 22:22:28 2022 From: philip.race at oracle.com (Philip Race) Date: Sun, 22 May 2022 15:22:28 -0700 Subject: pre-submit tests for github PRs Message-ID: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> Why is it that the vast majority of PRs are recording spurious looking failures of github pre-submit tests ? https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr There seems to be so much noise in these that I pay no attention to them any more (except for jcheck) but they seem to cause concern in some contributors who can't tell what they might have broken Even weirder is that we test Linux x86 there ?? When it isn't a mainstream platform. Why ? Especially since it seem to be the most common failure. -phil. From david.holmes at oracle.com Sun May 22 22:58:26 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 May 2022 08:58:26 +1000 Subject: pre-submit tests for github PRs In-Reply-To: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> References: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> Message-ID: On 23/05/2022 8:22 am, Philip Race wrote: > Why is it that the vast majority of PRs are recording spurious looking > failures of github pre-submit tests ? > > https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr > > There seems to be so much noise in these that I pay no attention to them > any more (except for jcheck) > but they seem to cause concern in some contributors who can't tell what > they might have broken > > Even weirder is that we test Linux x86 there ?? When it isn't a > mainstream platform. Why ? > Especially since it seem to be the most common failure. GHA tests a range of OpenJDK ports, not just the "mainstream platforms". The existing linux-86 failures (and others) are due to the Loom integration which only fully supports a couple of platforms and which broke all the other ports upon initial integration. Some folks in the community have been working through things to fix that. David > -phil. From philip.race at oracle.com Sun May 22 23:12:38 2022 From: philip.race at oracle.com (Philip Race) Date: Sun, 22 May 2022 16:12:38 -0700 Subject: pre-submit tests for github PRs In-Reply-To: References: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> Message-ID: <048421f1-aeaa-9ea7-6703-ec27b9e75b52@oracle.com> Yet right "at the top" of the list is Linux 86 ...? do we have no way to put it on some 2ndary list ? -phil. On 5/22/22 3:58 PM, David Holmes wrote: > On 23/05/2022 8:22 am, Philip Race wrote: >> Why is it that the vast majority of PRs are recording spurious >> looking failures of github pre-submit tests ? >> >> https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr >> >> There seems to be so much noise in these that I pay no attention to >> them any more (except for jcheck) >> but they seem to cause concern in some contributors who can't tell >> what they might have broken >> >> Even weirder is that we test Linux x86 there ?? When it isn't a >> mainstream platform. Why ? >> Especially since it seem to be the most common failure. > > GHA tests a range of OpenJDK ports, not just the "mainstream platforms". > > The existing linux-86 failures (and others) are due to the Loom > integration which only fully supports a couple of platforms and which > broke all the other ports upon initial integration. Some folks in the > community have been working through things to fix that. > > David > >> -phil. From dholmes at openjdk.java.net Mon May 23 06:41:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 06:41:40 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 All seems quite reasonable. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8718 From ihse at openjdk.java.net Mon May 23 10:12:29 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 23 May 2022 10:12:29 GMT Subject: RFR: 8287155: Additional make typos Message-ID: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com> Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though. ------------- Commit messages: - 8287155: Additional make typos Changes: https://git.openjdk.java.net/jdk/pull/8837/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8837&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287155 Stats: 15 lines in 13 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8837.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8837/head:pull/8837 PR: https://git.openjdk.java.net/jdk/pull/8837 From asotona at openjdk.java.net Mon May 23 10:40:40 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 23 May 2022 10:40:40 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v9] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio - Merge branch 'openjdk:master' into JDK-8244681 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base new case appeared in java.base by moving jdk.incubator.foreign code under java.base - Merge remote-tracking branch 'upstream/master' into JDK-8244681 # Conflicts: # make/test/BuildMicrobenchmark.gmk - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name - Merge branch 'openjdk:master' into JDK-8244681 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c9065915...455720ef ------------- Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08 Stats: 441 lines in 18 files changed: 438 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Mon May 23 11:02:32 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 23 May 2022 11:02:32 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v10] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module - Added man-page line about lossy-conversion lint ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/455720ef..4978c2a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08-09 Stats: 5 lines in 3 files changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From Alan.Bateman at oracle.com Mon May 23 11:41:46 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 May 2022 12:41:46 +0100 Subject: pre-submit tests for github PRs In-Reply-To: References: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> Message-ID: <2358065a-b198-2c4c-d0c9-c4822ad54817@oracle.com> On 22/05/2022 23:58, David Holmes wrote: > > GHA tests a range of OpenJDK ports, not just the "mainstream platforms". > > The existing linux-86 failures (and others) are due to the Loom > integration which only fully supports a couple of platforms and which > broke all the other ports upon initial integration. Some folks in the > community have been working through things to fix that. GHA is configured to cross build for most of these ports/configurations and they should pass. Running them is another matter of course. GHA does run some tests on linux-x86 and the x86_32 port does need work before it can run the tests with --enable-preview. Aleksey Shipil?v seems to be making good progress on it. -Alan From ioi.lam at oracle.com Mon May 23 14:53:35 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 23 May 2022 07:53:35 -0700 Subject: pre-submit tests for github PRs In-Reply-To: <2358065a-b198-2c4c-d0c9-c4822ad54817@oracle.com> References: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> <2358065a-b198-2c4c-d0c9-c4822ad54817@oracle.com> Message-ID: <423e8b1a-cd46-4e79-0e3d-0cf4dbe751a8@oracle.com> On 5/23/2022 4:41 AM, Alan Bateman wrote: > On 22/05/2022 23:58, David Holmes wrote: >> >> GHA tests a range of OpenJDK ports, not just the "mainstream platforms". >> >> The existing linux-86 failures (and others) are due to the Loom >> integration which only fully supports a couple of platforms and which >> broke all the other ports upon initial integration. Some folks in the >> community have been working through things to fix that. > > GHA is configured to cross build for most of these > ports/configurations and they should pass. Running them is another > matter of course. GHA does run some tests on linux-x86 and the x86_32 > port does need work before it can run the tests with --enable-preview. > Aleksey Shipil?v seems to be making good progress on it. > > -Alan Maybe it makes sense to disable the x86 GHA runs before the underlying issue is fixed? There's too much noise. From shade at redhat.com Mon May 23 15:05:20 2022 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 23 May 2022 17:05:20 +0200 Subject: pre-submit tests for github PRs In-Reply-To: <423e8b1a-cd46-4e79-0e3d-0cf4dbe751a8@oracle.com> References: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> <2358065a-b198-2c4c-d0c9-c4822ad54817@oracle.com> <423e8b1a-cd46-4e79-0e3d-0cf4dbe751a8@oracle.com> Message-ID: <19a13517-e8b8-e806-bedb-8d2a022935ef@redhat.com> On 5/23/22 16:53, Ioi Lam wrote: > On 5/23/2022 4:41 AM, Alan Bateman wrote: >> On 22/05/2022 23:58, David Holmes wrote: >>> >>> GHA tests a range of OpenJDK ports, not just the "mainstream platforms". >>> >>> The existing linux-86 failures (and others) are due to the Loom >>> integration which only fully supports a couple of platforms and which >>> broke all the other ports upon initial integration. Some folks in the >>> community have been working through things to fix that. >> >> GHA is configured to cross build for most of these >> ports/configurations and they should pass. Running them is another >> matter of course. GHA does run some tests on linux-x86 and the x86_32 >> port does need work before it can run the tests with --enable-preview. >> Aleksey Shipil?v seems to be making good progress on it. >> >> -Alan > > Maybe it makes sense to disable the x86 GHA runs before the underlying > issue is fixed? There's too much noise. There is a slightly better way to do it: https://github.com/openjdk/jdk/pull/8843 -- Thanks, -Aleksey From philip.race at oracle.com Mon May 23 15:14:09 2022 From: philip.race at oracle.com (Philip Race) Date: Mon, 23 May 2022 08:14:09 -0700 Subject: pre-submit tests for github PRs In-Reply-To: <19a13517-e8b8-e806-bedb-8d2a022935ef@redhat.com> References: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> <2358065a-b198-2c4c-d0c9-c4822ad54817@oracle.com> <423e8b1a-cd46-4e79-0e3d-0cf4dbe751a8@oracle.com> <19a13517-e8b8-e806-bedb-8d2a022935ef@redhat.com> Message-ID: <5def314e-d0e5-68ec-cd99-847e72cce120@oracle.com> BTW I am wondering whether I should believe this explanation since it does pass sometimes, eg : https://github.com/openjdk/jdk/pull/8820 How is that possible ? -phil On 5/23/22 8:05 AM, Aleksey Shipilev wrote: > On 5/23/22 16:53, Ioi Lam wrote: >> On 5/23/2022 4:41 AM, Alan Bateman wrote: >>> On 22/05/2022 23:58, David Holmes wrote: >>>> >>>> GHA tests a range of OpenJDK ports, not just the "mainstream >>>> platforms". >>>> >>>> The existing linux-86 failures (and others) are due to the Loom >>>> integration which only fully supports a couple of platforms and which >>>> broke all the other ports upon initial integration. Some folks in the >>>> community have been working through things to fix that. >>> >>> GHA is configured to cross build for most of these >>> ports/configurations and they should pass. Running them is another >>> matter of course. GHA does run some tests on linux-x86 and the x86_32 >>> port does need work before it can run the tests with --enable-preview. >>> Aleksey Shipil?v seems to be making good progress on it. >>> >>> -Alan >> >> Maybe it makes sense to disable the x86 GHA runs before the underlying >> issue is fixed? There's too much noise. > > There is a slightly better way to do it: > ? https://github.com/openjdk/jdk/pull/8843 > From christoph.langer at sap.com Mon May 23 15:18:18 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 May 2022 15:18:18 +0000 Subject: pre-submit tests for github PRs In-Reply-To: <5def314e-d0e5-68ec-cd99-847e72cce120@oracle.com> References: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> <2358065a-b198-2c4c-d0c9-c4822ad54817@oracle.com> <423e8b1a-cd46-4e79-0e3d-0cf4dbe751a8@oracle.com> <19a13517-e8b8-e806-bedb-8d2a022935ef@redhat.com> <5def314e-d0e5-68ec-cd99-847e72cce120@oracle.com> Message-ID: Hi, that's because the PR is a based on a pre-loom version of master. Best regards Christoph > -----Original Message----- > From: build-dev On Behalf Of Philip Race > Sent: Montag, 23. Mai 2022 17:14 > To: Aleksey Shipilev ; Ioi Lam ; > build-dev at openjdk.java.net > Subject: Re: pre-submit tests for github PRs > > BTW I am wondering whether I should believe this explanation since it does > pass sometimes, > > eg : > > https://github.com/openjdk/jdk/pull/8820 > > How is that possible ? > > -phil > > On 5/23/22 8:05 AM, Aleksey Shipilev wrote: > > On 5/23/22 16:53, Ioi Lam wrote: > >> On 5/23/2022 4:41 AM, Alan Bateman wrote: > >>> On 22/05/2022 23:58, David Holmes wrote: > >>>> > >>>> GHA tests a range of OpenJDK ports, not just the "mainstream > >>>> platforms". > >>>> > >>>> The existing linux-86 failures (and others) are due to the Loom > >>>> integration which only fully supports a couple of platforms and > >>>> which broke all the other ports upon initial integration. Some > >>>> folks in the community have been working through things to fix that. > >>> > >>> GHA is configured to cross build for most of these > >>> ports/configurations and they should pass. Running them is another > >>> matter of course. GHA does run some tests on linux-x86 and the > >>> x86_32 port does need work before it can run the tests with --enable- > preview. > >>> Aleksey Shipil?v seems to be making good progress on it. > >>> > >>> -Alan > >> > >> Maybe it makes sense to disable the x86 GHA runs before the > >> underlying issue is fixed? There's too much noise. > > > > There is a slightly better way to do it: > > ? https://github.com/openjdk/jdk/pull/8843 > > From philip.race at oracle.com Mon May 23 15:20:05 2022 From: philip.race at oracle.com (Philip Race) Date: Mon, 23 May 2022 08:20:05 -0700 Subject: pre-submit tests for github PRs In-Reply-To: References: <152f2dcc-068a-6fbd-b8bb-72a025dd8741@oracle.com> <2358065a-b198-2c4c-d0c9-c4822ad54817@oracle.com> <423e8b1a-cd46-4e79-0e3d-0cf4dbe751a8@oracle.com> <19a13517-e8b8-e806-bedb-8d2a022935ef@redhat.com> <5def314e-d0e5-68ec-cd99-847e72cce120@oracle.com> Message-ID: <287898be-f7d2-6998-54d2-5175bd094911@oracle.com> Ah. -phil On 5/23/22 8:18 AM, Langer, Christoph wrote: > Hi, > > that's because the PR is a based on a pre-loom version of master. > > Best regards > Christoph > >> -----Original Message----- >> From: build-dev On Behalf Of Philip Race >> Sent: Montag, 23. Mai 2022 17:14 >> To: Aleksey Shipilev ; Ioi Lam ; >> build-dev at openjdk.java.net >> Subject: Re: pre-submit tests for github PRs >> >> BTW I am wondering whether I should believe this explanation since it does >> pass sometimes, >> >> eg : >> >> https://github.com/openjdk/jdk/pull/8820 >> >> How is that possible ? >> >> -phil >> >> On 5/23/22 8:05 AM, Aleksey Shipilev wrote: >>> On 5/23/22 16:53, Ioi Lam wrote: >>>> On 5/23/2022 4:41 AM, Alan Bateman wrote: >>>>> On 22/05/2022 23:58, David Holmes wrote: >>>>>> GHA tests a range of OpenJDK ports, not just the "mainstream >>>>>> platforms". >>>>>> >>>>>> The existing linux-86 failures (and others) are due to the Loom >>>>>> integration which only fully supports a couple of platforms and >>>>>> which broke all the other ports upon initial integration. Some >>>>>> folks in the community have been working through things to fix that. >>>>> GHA is configured to cross build for most of these >>>>> ports/configurations and they should pass. Running them is another >>>>> matter of course. GHA does run some tests on linux-x86 and the >>>>> x86_32 port does need work before it can run the tests with --enable- >> preview. >>>>> Aleksey Shipil?v seems to be making good progress on it. >>>>> >>>>> -Alan >>>> Maybe it makes sense to disable the x86 GHA runs before the >>>> underlying issue is fixed? There's too much noise. >>> There is a slightly better way to do it: >>> ? https://github.com/openjdk/jdk/pull/8843 >>> From dchuyko at openjdk.java.net Mon May 23 15:47:55 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Mon, 23 May 2022 15:47:55 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Fri, 20 May 2022 08:36:28 GMT, Magnus Ihse Bursie wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. >> >> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. >> >> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. >> >> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: >> >> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. >> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with >> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse >> >> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. > > make/autoconf/jvm-features.m4 line 442: > >> 440: JVM_FEATURES_VARIANT_FILTER="link-time-opt opt-size" >> 441: fi >> 442: # Filter out hardlse feature by default > > You should not set up a PLATFORM filter in `JVM_FEATURES_PREPARE_VARIANT`. > > In fact, you will need a `JVM_FEATURES_CHECK_HARD_LSE`, which verifies that it can only be enabled on aarch64. See e.g. `JVM_FEATURES_CHECK_JVMCI` foor inspiration on how to write this and where to call it. I suggest you set up `JVM_FEATURES_PLATFORM_FILTER` in that function as well. Magnus, thank you for the comments. I'm taking a direction suggested by Andrew and Nick -- linux-aarch64 only solution without build configuration feature, determined by actual compiler flags. Will update the PR shortly after some final testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From dchuyko at openjdk.java.net Mon May 23 16:05:16 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Mon, 23 May 2022 16:05:16 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v2] In-Reply-To: References: Message-ID: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. Dmitry Chuyko has updated the pull request incrementally with two additional commits since the last revision: - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on - Revert "hardlse feature" This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8779/files - new: https://git.openjdk.java.net/jdk/pull/8779/files/87b3cbb9..1287cce3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=00-01 Stats: 277 lines in 6 files changed: 74 ins; 190 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8779/head:pull/8779 PR: https://git.openjdk.java.net/jdk/pull/8779 From dchuyko at openjdk.java.net Mon May 23 16:12:34 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Mon, 23 May 2022 16:12:34 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v3] In-Reply-To: References: Message-ID: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. Dmitry Chuyko 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 five additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8282322 - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on - Revert "hardlse feature" This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. - Merge branch 'openjdk:master' into JDK-8282322 - hardlse feature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8779/files - new: https://git.openjdk.java.net/jdk/pull/8779/files/1287cce3..f7c8378a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=01-02 Stats: 8571 lines in 343 files changed: 4112 ins; 3026 del; 1433 mod Patch: https://git.openjdk.java.net/jdk/pull/8779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8779/head:pull/8779 PR: https://git.openjdk.java.net/jdk/pull/8779 From dchuyko at openjdk.java.net Mon May 23 16:12:34 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Mon, 23 May 2022 16:12:34 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:05:16 GMT, Dmitry Chuyko wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. >> >> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. >> >> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. >> >> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: >> >> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. >> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with >> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse >> >> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. > > Dmitry Chuyko has updated the pull request incrementally with two additional commits since the last revision: > > - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on > - Revert "hardlse feature" > > This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. New variant turns on using LSE atomics statically when __ARM_FEATURE_ATOMICS compiler feature is on. Prefetch is left only to non-LSE case, the kernel seems to do the same. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Mon May 23 16:56:00 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 23 May 2022 16:56:00 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v3] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:12:34 GMT, Dmitry Chuyko wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. >> >> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. >> >> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. >> >> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: >> >> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. >> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with >> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse >> >> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. > > Dmitry Chuyko 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 five additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8282322 > - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on > - Revert "hardlse feature" > > This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. > - Merge branch 'openjdk:master' into JDK-8282322 > - hardlse feature src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S line 291: > 289: #endif > 290: 1: mov x0, x3 > 291: ret Oh gosh, I find all those `#if`s really hard to read. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From anleonar at redhat.com Mon May 23 17:16:55 2022 From: anleonar at redhat.com (Andrew Leonard) Date: Mon, 23 May 2022 18:16:55 +0100 Subject: Reproducible MacOS Codesign'ed builds? Message-ID: Hi, Has anyone looked into reproducible builds for codesign'd MacOS builds? Basically Apple codesigning is non-deterministic, which is not surprisingly I guess, so naturally makes reproducible builds a bit tricky. The general theme for this sort of issue seems to be to remove the signature before comparing (codesign --remove-signature X.dylib). Which i've attempted, and works to a degree. The single stumbling block being the signing of jpackageapplauncher in jdk.jpackage, which then gets placed in the jmod's classes resource section, leading to different module "hash" in java.base/../module-info.class, and also a different "modules" file. Has anyone else tried to tackle this problem? Could we store jpackageapplauncher somewhere that would not end up in the jmod classes...but still be securely loadable? ( https://github.com/openjdk/jdk/blob/646c8aaeeccb494c72ff84c6e0f303f790be0ba9/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#L284 ) Thanks Andrew From ihse at openjdk.java.net Mon May 23 17:34:18 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 23 May 2022 17:34:18 GMT Subject: RFR: 8287174: Remove deprecated configure arguments Message-ID: <0Pj0EvEEHkdqQ5Qsj_w9WdsLbb2tJxtFbrTNNk0wPuA=.dd4fe751-66a7-44c2-9a88-d2d7475cc6d7@github.com> We have a bunch of configure arguments that has been deprecated for multiple releases. These should be removed. In effect, this will raise an error instead of a warning if these argument is included on the command line for configure. The deprecated arguments stopped having any effect when they were deprecated. ------------- Commit messages: - 8287174: Remove deprecated configure arguments Changes: https://git.openjdk.java.net/jdk/pull/8852/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8852&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287174 Stats: 23 lines in 3 files changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8852/head:pull/8852 PR: https://git.openjdk.java.net/jdk/pull/8852 From shade at openjdk.java.net Mon May 23 17:49:50 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 17:49:50 GMT Subject: RFR: 8287174: Remove deprecated configure arguments In-Reply-To: <0Pj0EvEEHkdqQ5Qsj_w9WdsLbb2tJxtFbrTNNk0wPuA=.dd4fe751-66a7-44c2-9a88-d2d7475cc6d7@github.com> References: <0Pj0EvEEHkdqQ5Qsj_w9WdsLbb2tJxtFbrTNNk0wPuA=.dd4fe751-66a7-44c2-9a88-d2d7475cc6d7@github.com> Message-ID: On Mon, 23 May 2022 17:25:30 GMT, Magnus Ihse Bursie wrote: > We have a bunch of configure arguments that has been deprecated for multiple releases. These should be removed. In effect, this will raise an error instead of a warning if these argument is included on the command line for configure. The deprecated arguments stopped having any effect when they were deprecated. Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8852 From lancea at openjdk.java.net Mon May 23 20:03:55 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 23 May 2022 20:03:55 GMT Subject: RFR: 8287155: Additional make typos In-Reply-To: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com> References: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com> Message-ID: On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote: > Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8837 From iris at openjdk.java.net Mon May 23 20:35:56 2022 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 23 May 2022 20:35:56 GMT Subject: RFR: 8287155: Additional make typos In-Reply-To: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com> References: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com> Message-ID: On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote: > Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8837 From aivanov at openjdk.java.net Mon May 23 20:46:23 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 May 2022 20:46:23 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code [v2] In-Reply-To: References: Message-ID: <6pmdug3Hpy1LPgcb-OIdMP6XuOWpWYngOju7mFPdDV4=.a68d1c15-58a3-4ffa-b94d-a1a14666f9eb@github.com> > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge master - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'an? an?' in source code - 8284209: Replace remaining usages of 'a the' in source code - ... and 2 more: https://git.openjdk.java.net/jdk/compare/5b7d066c...fab0a4bb ------------- Changes: https://git.openjdk.java.net/jdk/pull/8771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01 Stats: 50 lines in 40 files changed: 0 ins; 2 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/8771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771 PR: https://git.openjdk.java.net/jdk/pull/8771 From ihse at openjdk.java.net Mon May 23 21:00:56 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 23 May 2022 21:00:56 GMT Subject: Integrated: 8287155: Additional make typos In-Reply-To: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com> References: <5KBRDG8hPsM5YlGkxcWKD5c3txoOo4ssMkWe765auU8=.4a493f63-a0e4-47c8-818b-53bdefee6290@github.com> Message-ID: On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote: > Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though. This pull request has now been integrated. Changeset: 02fec1e6 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/02fec1e6e5b6728c13763718c98cf5db68b1cce3 Stats: 15 lines in 13 files changed: 0 ins; 0 del; 15 mod 8287155: Additional make typos Reviewed-by: lancea, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/8837 From kbarrett at openjdk.java.net Mon May 23 22:50:46 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 23 May 2022 22:50:46 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression [v2] In-Reply-To: References: Message-ID: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into no-deprecate - cleanup Windows deprecation warning suppression ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8718/files - new: https://git.openjdk.java.net/jdk/pull/8718/files/dd39fb83..cbee140c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8718&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8718&range=00-01 Stats: 27751 lines in 853 files changed: 14074 ins; 9711 del; 3966 mod Patch: https://git.openjdk.java.net/jdk/pull/8718.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8718/head:pull/8718 PR: https://git.openjdk.java.net/jdk/pull/8718 From kbarrett at openjdk.java.net Mon May 23 22:50:47 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 23 May 2022 22:50:47 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Tue, 17 May 2022 06:30:03 GMT, David Holmes wrote: >> Please review this cleanup of deprecation warning suppression when building >> for Windows. >> >> This change consists of several parts. >> >> (1) Remove the global deprecation warning suppression when building HotSpot >> for Windows. >> >> (2) Add macro definitions requesting suppression of selected sets of >> deprecation warnings when building HotSpot for Windows. >> >> (3) Remove unnecessary forwarding macros for various POSIX functions in >> globalDefinitions_visCPP.hpp. These were provided to avoid deprecation >> warnings (that were previously also being suppressed by the global request). >> They are now covered by the new macros provided by change (2) above. >> >> An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item >> (2)) and either retain the forwarding macros or define os:: wrapper functions >> for all of the affected functions. We might eventually do the latter because >> of other reasons for avoiding some of these functions, but the approach being >> taken here is simpler. >> >> For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: >> https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility >> https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 >> >> Similarly for _CRT_SECURE_NO_WARNINGS. >> >> Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find >> any documentation for the latter). But it might be better to not supress the >> warnings and instead use the alternatives (JDK-8286781). >> >> Testing: >> mach5 tier1 > > Sorry Kim I'm having trouble seeing what change corresponds to (1) ?? > > Also the PR talks only about hotspot, but you're changing the JDK flags as well. ?? Thanks @dholmes-ora and @magicus for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8718 From kbarrett at openjdk.java.net Mon May 23 22:50:47 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 23 May 2022 22:50:47 GMT Subject: Integrated: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: 782ae380 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/782ae3801c63945ed977782fe15e8e911f7f9656 Stats: 21 lines in 4 files changed: 2 ins; 13 del; 6 mod 8286262: Windows: Cleanup deprecation warning suppression Reviewed-by: ihse, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8718 From dholmes at openjdk.java.net Tue May 24 05:47:52 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 05:47:52 GMT Subject: RFR: 8287174: Remove deprecated configure arguments In-Reply-To: <0Pj0EvEEHkdqQ5Qsj_w9WdsLbb2tJxtFbrTNNk0wPuA=.dd4fe751-66a7-44c2-9a88-d2d7475cc6d7@github.com> References: <0Pj0EvEEHkdqQ5Qsj_w9WdsLbb2tJxtFbrTNNk0wPuA=.dd4fe751-66a7-44c2-9a88-d2d7475cc6d7@github.com> Message-ID: On Mon, 23 May 2022 17:25:30 GMT, Magnus Ihse Bursie wrote: > We have a bunch of configure arguments that has been deprecated for multiple releases. These should be removed. In effect, this will raise an error instead of a warning if these argument is included on the command line for configure. The deprecated arguments stopped having any effect when they were deprecated. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8852 From clanger at openjdk.java.net Tue May 24 06:49:04 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 24 May 2022 06:49:04 GMT Subject: RFR: 8287202: GHA: Add macOS aarch64 to the list of default platforms for workflow_dispatch event Message-ID: It seems that it was forgotten to add the macOS aarch64 platform to the default platforms of workflow_dispatch. Let's fix this. ------------- Commit messages: - JDK-8287202 Changes: https://git.openjdk.java.net/jdk/pull/8861/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8861&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287202 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8861.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8861/head:pull/8861 PR: https://git.openjdk.java.net/jdk/pull/8861 From ihse at openjdk.java.net Tue May 24 07:56:51 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 24 May 2022 07:56:51 GMT Subject: Integrated: 8287174: Remove deprecated configure arguments In-Reply-To: <0Pj0EvEEHkdqQ5Qsj_w9WdsLbb2tJxtFbrTNNk0wPuA=.dd4fe751-66a7-44c2-9a88-d2d7475cc6d7@github.com> References: <0Pj0EvEEHkdqQ5Qsj_w9WdsLbb2tJxtFbrTNNk0wPuA=.dd4fe751-66a7-44c2-9a88-d2d7475cc6d7@github.com> Message-ID: On Mon, 23 May 2022 17:25:30 GMT, Magnus Ihse Bursie wrote: > We have a bunch of configure arguments that has been deprecated for multiple releases. These should be removed. In effect, this will raise an error instead of a warning if these argument is included on the command line for configure. The deprecated arguments stopped having any effect when they were deprecated. This pull request has now been integrated. Changeset: cf57d72f Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/cf57d72fe8f40810f386413fe6e8c3c5dafab01f Stats: 23 lines in 3 files changed: 0 ins; 23 del; 0 mod 8287174: Remove deprecated configure arguments Reviewed-by: shade, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8852 From ihse at openjdk.java.net Tue May 24 08:20:40 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 24 May 2022 08:20:40 GMT Subject: RFR: 8287202: GHA: Add macOS aarch64 to the list of default platforms for workflow_dispatch event In-Reply-To: References: Message-ID: On Tue, 24 May 2022 06:41:52 GMT, Christoph Langer wrote: > It seems that it was forgotten to add the macOS aarch64 platform to the default platforms of workflow_dispatch. Let's fix this. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8861 From shade at openjdk.java.net Tue May 24 08:28:05 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 May 2022 08:28:05 GMT Subject: RFR: 8287202: GHA: Add macOS aarch64 to the list of default platforms for workflow_dispatch event In-Reply-To: References: Message-ID: On Tue, 24 May 2022 06:41:52 GMT, Christoph Langer wrote: > It seems that it was forgotten to add the macOS aarch64 platform to the default platforms of workflow_dispatch. Let's fix this. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8861 From magnus.ihse.bursie at oracle.com Tue May 24 08:52:57 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 May 2022 10:52:57 +0200 Subject: Reproducible MacOS Codesign'ed builds? In-Reply-To: References: Message-ID: <3b5cb34b-7ae3-51a2-2741-59b890c1081c@oracle.com> On 2022-05-23 19:16, Andrew Leonard wrote: > Hi, > Has anyone looked into reproducible builds for codesign'd MacOS builds? > Basically Apple codesigning is non-deterministic, which is not surprisingly > I guess, so naturally makes reproducible builds a bit tricky. The general > theme for this sort of issue seems to be to remove the signature before > comparing (codesign --remove-signature X.dylib). Which i've attempted, and > works to a degree. The single stumbling block being the signing of > jpackageapplauncher in jdk.jpackage, which then gets placed in the jmod's > classes resource section, leading to different module "hash" in > java.base/../module-info.class, and also a different "modules" file. > Has anyone else tried to tackle this problem? Could we store > jpackageapplauncher somewhere that would not end up in the jmod > classes...but still be securely loadable? ( > https://github.com/openjdk/jdk/blob/646c8aaeeccb494c72ff84c6e0f303f790be0ba9/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#L284 Unfortunately, I think this is an unsolvable problem. :-( We need to package all needed resources with the jmod, and jdk.jpackage needs its launchers. If we were do to anything differently, then suddenly the jdk.jpackage module would be different -- you will not be able to create a stripped-down image containing jdk.jpackage that will work properly, without also copying the launcher on the side. If anything, I suggest you create an image without jdk.jpackage, if you want to have a reproducible build on macOS. Personally, I have not spent much time and effort yet looking at reproducibility on macOS. I think we have quite some way to go there, compared with Linux and Windows. /Magnus From aivanov at openjdk.java.net Tue May 24 09:52:29 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 09:52:29 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code [v3] In-Reply-To: References: Message-ID: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update copyright to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8771/files - new: https://git.openjdk.java.net/jdk/pull/8771/files/fab0a4bb..4d529f79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01-02 Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/8771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771 PR: https://git.openjdk.java.net/jdk/pull/8771 From lancea at openjdk.java.net Tue May 24 09:58:42 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 24 May 2022 09:58:42 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code [v3] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 09:52:29 GMT, Alexey Ivanov wrote: >> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? >> >> It's the last issue in the series, and it still touches different areas of the code. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright to 2022 Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8771 From ihse at openjdk.java.net Tue May 24 17:18:46 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 24 May 2022 17:18:46 GMT Subject: RFR: 8287254: Clean up Xcode sysroot logic Message-ID: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com> The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is hard to follow. This should be straightened out. We also expose variables that are no longer used. So there's a bit of related cleanup. The new code is more or less functionally equivalent to the old. There were some corner cases which the old code did not handle well; this has now been improved. I've also added yet another method of trying to get the SDK root before falling back to the system library, by using `xcrun --show-sdk-path`. In an ideal world, the sysroot flags to `mig` should be set in configure, e.g. as `MIG_FLAGS` or `MIG_SYSROOT_FLAGS`. I can't be bothered to do that for a single call to `mig`, though. As always, changes like this that depend on the environment is tricky to test. I've tried running it on a couple of different macs, with and without a devkit. ------------- Commit messages: - Make Xcode SDK locating more robust - * Clean up BASIC_SETUP_XCODE_SYSROOT - Don't export SDKROOT - Move sdk setup to BASIC_SETUP_XCODE_SYSROOT Changes: https://git.openjdk.java.net/jdk/pull/8872/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8872&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287254 Stats: 200 lines in 4 files changed: 91 ins; 98 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8872.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8872/head:pull/8872 PR: https://git.openjdk.java.net/jdk/pull/8872 From erikj at openjdk.java.net Tue May 24 19:49:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 24 May 2022 19:49:54 GMT Subject: RFR: 8287254: Clean up Xcode sysroot logic In-Reply-To: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com> References: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com> Message-ID: On Tue, 24 May 2022 17:09:10 GMT, Magnus Ihse Bursie wrote: > The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is hard to follow. This should be straightened out. We also expose variables that are no longer used. So there's a bit of related cleanup. > > The new code is more or less functionally equivalent to the old. There were some corner cases which the old code did not handle well; this has now been improved. I've also added yet another method of trying to get the SDK root before falling back to the system library, by using `xcrun --show-sdk-path`. > > In an ideal world, the sysroot flags to `mig` should be set in configure, e.g. as `MIG_FLAGS` or `MIG_SYSROOT_FLAGS`. I can't be bothered to do that for a single call to `mig`, though. > > As always, changes like this that depend on the environment is tricky to test. I've tried running it on a couple of different macs, with and without a devkit. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8872 From aivanov at openjdk.java.net Tue May 24 20:12:09 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 20:12:09 GMT Subject: Integrated: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. This pull request has now been integrated. Changeset: 9b7e42c0 Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/9b7e42c0f078db778dda1011d85cd92e3e4eb979 Stats: 74 lines in 40 files changed: 0 ins; 2 del; 72 mod 8284209: Replace remaining usages of 'a the' in source code Reviewed-by: lancea, wetmore, dfuchs, iris, jjg, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/8771 From kbarrett at openjdk.java.net Wed May 25 01:54:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 25 May 2022 01:54:55 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 08:40:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge remote-tracking branch 'upstream/master' into gcc12-warnings > - Use getter function to access "_data" > - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp > - revert changes for memnode.cpp and type.cpp > - Add assert to check the range of BasicType > - Merge remote-tracking branch 'upstream/master' into HEAD > - Revert change for java.c , parse_manifest.c , LinuxPackage.c > - Calculate char offset before realloc() > - Use return value from JLI_Snprintf > - Avoid pragma error in before GCC 12 > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 Changes requested by kbarrett (Reviewer). src/hotspot/share/oops/array.hpp line 102: > 100: // standard operations > 101: int length() const { return _length; } > 102: T* data() const { return reinterpret_cast(reinterpret_cast(this) + base_offset_in_bytes()); } Adding the const-qualifier to the `data()` function and then implicitly casting it away (by casting through intptr_t) is wrong. Either don't const-qualify (and leave it to some future use that needs such to address appropriately), or have two functions. Also, the line length is excessive. So this: T* data() { return reinterpret_cast( reinterpret_cast(this) + base_offset_in_bytes()); } and optionally add this: const T* data() const { return reinterpret_cast( reinterpret_cast(this) + base_offset_in_bytes()); } ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Wed May 25 01:54:56 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 25 May 2022 01:54:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <2Fd9HKYBsrWvMvJoKwAL2tN010yXbzMGA15Vz1e9aRU=.80246fcf-ba7e-4ec7-aea3-ec2aa011e863@github.com> On Sun, 22 May 2022 16:45:11 GMT, Kim Barrett wrote: >> It might be GCC bug... >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 >> >> This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). > > I don't see the similarity. That gcc bug is about literals used as addresses, > which get treated (suggested inappropriately) as NULL+offset, with NULL+offset > being a cause of warnings. I don't see that happening in our case. That is, > in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL > that I can see. > > It's hard for me to investigate this any further just by perusing the code, so > I'm in the process of getting set up to build with gcc12.x. That will let me > do some experiments. It may take me a few days to get to that point though. I spent some time looking into this one. I agree there is a false positive here, and there doesn't seem to be a better solution than suppressing the warning. I would prefer the change below, rather than what's proposed. Also eliminate the changes to utilities/compilerWarnings files. This is a very gcc-specific issue; there's no reason to generalize the solution. The reason for relocating the suppression is to be able to describe the issue in more detail in a context where that description makes sense. template inline void JfrTraceIdBits::store(jbyte bits, const T* ptr) { assert(ptr != NULL, "invariant"); // gcc12 warns "writing 1 byte into a region of size 0" when T == Klass. // The warning seems to be a false positive. And there is no warning for // other types that use the same mechanisms. The warning also sometimes // goes away with minor code perturbations, such as replacing function calls // with equivalent code directly inlined. PRAGMA_DIAG_PUSH PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") set(bits, traceid_tag_byte(ptr)); PRAGMA_DIAG_POP } ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ihse at openjdk.java.net Wed May 25 08:09:00 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 25 May 2022 08:09:00 GMT Subject: Integrated: 8287254: Clean up Xcode sysroot logic In-Reply-To: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com> References: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com> Message-ID: On Tue, 24 May 2022 17:09:10 GMT, Magnus Ihse Bursie wrote: > The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is hard to follow. This should be straightened out. We also expose variables that are no longer used. So there's a bit of related cleanup. > > The new code is more or less functionally equivalent to the old. There were some corner cases which the old code did not handle well; this has now been improved. I've also added yet another method of trying to get the SDK root before falling back to the system library, by using `xcrun --show-sdk-path`. > > In an ideal world, the sysroot flags to `mig` should be set in configure, e.g. as `MIG_FLAGS` or `MIG_SYSROOT_FLAGS`. I can't be bothered to do that for a single call to `mig`, though. > > As always, changes like this that depend on the environment is tricky to test. I've tried running it on a couple of different macs, with and without a devkit. This pull request has now been integrated. Changeset: d889319a Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/d889319a86101e944aefd4ad7f300505abbe5b30 Stats: 200 lines in 4 files changed: 91 ins; 98 del; 11 mod 8287254: Clean up Xcode sysroot logic Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8872 From clanger at openjdk.java.net Wed May 25 08:19:57 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 25 May 2022 08:19:57 GMT Subject: Integrated: 8287202: GHA: Add macOS aarch64 to the list of default platforms for workflow_dispatch event In-Reply-To: References: Message-ID: On Tue, 24 May 2022 06:41:52 GMT, Christoph Langer wrote: > It seems that it was forgotten to add the macOS aarch64 platform to the default platforms of workflow_dispatch. Let's fix this. This pull request has now been integrated. Changeset: f7a37f58 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/f7a37f58862d08adbf8fb141bf43c362bda7fd16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8287202: GHA: Add macOS aarch64 to the list of default platforms for workflow_dispatch event Reviewed-by: ihse, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8861 From stuefe at openjdk.java.net Wed May 25 09:09:13 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 25 May 2022 09:09:13 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v9] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 14:54:39 GMT, Christian Hagedorn wrote: > Thanks Thomas for doing the testing! Hi Christian, I can see no problems on ppcle attributable to your test. However, I may overlook something since tests are still failing all over the place because of loom. I see test errors in TestDwarf on ppcle and x64, however. On x64: ----------System.out:(52/5198)---------- Command line: [/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/bin/java -cp /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/runtime/ErrorHandling/TestDwarf.d:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg/runtime/ErrorHandling:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/test/lib:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/lib:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/javatest.jar:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/jtreg.jar -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotsp ot_tier1_work/tmp -Djava.io.tmpdir=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Xlog:dwarf=info -XX:-CreateCoredumpOnCrash -Xcomp -XX:CICrashAt=1 --version ] [2022-05-24T18:37:00.974121691Z] Gathering output for process 44490 [2022-05-24T18:37:02.872100892Z] Waiting for completion for process 44490 [2022-05-24T18:37:02.872338192Z] Waiting for completion finished for process 44490 Output and diagnostic info for process 44490 was saved into 'pid-44490-output.log' [2022-05-24T18:37:02.889455876Z] Waiting for completion for process 44490 [2022-05-24T18:37:02.889604189Z] Waiting for completion finished for process 44490 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/c1_Compilation.cpp:616 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/c1/c1_Compilation.cpp:616), pid=44490, tid=44505 # assert(CICrashAt < 0 || (uintx)_env->compile_id() != (uintx)CICrashAt) failed: just as planned # # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.openjdk.jdk-dev) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.openjdk.jdk-dev, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x73ca34] Compilation::~Compilation()+0x84 # # CreateCoredumpOnCrash turned off, no core file dumped # # An error report file with more information is saved as: # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/hs_err_pid44490.log [1.835s][info][dwarf] Open DWARF file: /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.debuginfo [1.842s][info][dwarf] Failed to parse the line number program header correctly. [1.842s][info][dwarf] Failed to process the line number program correctly. [1.842s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x0074176a [1.843s][info][dwarf] Failed to parse the line number program header correctly. [1.843s][info][dwarf] Failed to process the line number program correctly. [1.843s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05011 [1.845s][info][dwarf] Failed to parse the line number program header correctly. [1.845s][info][dwarf] Failed to process the line number program correctly. [1.845s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05b78 [1.849s][info][dwarf] Failed to parse the line number program header correctly. [1.849s][info][dwarf] Failed to process the line number program correctly. [1.849s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018d49d3 [1.852s][info][dwarf] Failed to parse the line number program header correctly. [1.852s][info][dwarf] Failed to process the line number program correctly. [1.852s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018de546 [1.855s][info][dwarf] Failed to parse the line number program header correctly. [1.855s][info][dwarf] Failed to process the line number program correctly. [1.855s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x014d86e9 # # Compiler replay data is saved as: # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/replay_pid44490.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # hs_err_file: hs_err_pid44490.log ----------System.err:(15/1242)---------- java.lang.RuntimeException: Could not find filename or line number in "V [libjvm.so+0x74176a] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1aa": expected true, was false at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertTrue(Asserts.java:486) at TestDwarf.runAndCheck(TestDwarf.java:163) at TestDwarf.test(TestDwarf.java:99) at TestDwarf.main(TestDwarf.java:90) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1585) ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From ysuenaga at openjdk.java.net Wed May 25 09:16:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 25 May 2022 09:16:43 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Change Array::data() implementation - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/042c1c70..17cda224 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=07-08 Stats: 39 lines in 4 files changed: 18 ins; 18 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Wed May 25 09:16:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 25 May 2022 09:16:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: <9kogffvvtXsQPgsozHqM-4XQlGBFZv8JVURdlpX0W4s=.68aa1f9e-4abd-405a-accf-e931090623ea@github.com> On Wed, 25 May 2022 01:50:57 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge remote-tracking branch 'upstream/master' into gcc12-warnings >> - Use getter function to access "_data" >> - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp >> - revert changes for memnode.cpp and type.cpp >> - Add assert to check the range of BasicType >> - Merge remote-tracking branch 'upstream/master' into HEAD >> - Revert change for java.c , parse_manifest.c , LinuxPackage.c >> - Calculate char offset before realloc() >> - Use return value from JLI_Snprintf >> - Avoid pragma error in before GCC 12 >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 > > src/hotspot/share/oops/array.hpp line 102: > >> 100: // standard operations >> 101: int length() const { return _length; } >> 102: T* data() const { return reinterpret_cast(reinterpret_cast(this) + base_offset_in_bytes()); } > > Adding the const-qualifier to the `data()` function and then implicitly > casting it away (by casting through intptr_t) is wrong. Either don't > const-qualify (and leave it to some future use that needs such to address > appropriately), or have two functions. Also, the line length is excessive. > So this: > > > T* data() { > return reinterpret_cast( > reinterpret_cast(this) + base_offset_in_bytes()); > } > > and optionally add this: > > const T* data() const { > return reinterpret_cast( > reinterpret_cast(this) + base_offset_in_bytes()); > } Thanks a lot @kimbarrett ! I updated around stringop-overflow warning in jfrTraceIdBits.inline.hpp , and added two `data()` in `Array` class. They works fine on my GCC 12 on Fedora 36. Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From naoto at openjdk.java.net Wed May 25 16:50:32 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 25 May 2022 16:50:32 GMT Subject: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter Message-ID: Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones. ------------- Commit messages: - 8287187: Utilize HashMap.newHashMap() in CLDRConverter Changes: https://git.openjdk.java.net/jdk/pull/8887/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287187 Stats: 65 lines in 1 file changed: 8 ins; 1 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/8887.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8887/head:pull/8887 PR: https://git.openjdk.java.net/jdk/pull/8887 From naoto at openjdk.java.net Wed May 25 17:15:18 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 25 May 2022 17:15:18 GMT Subject: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter [v2] In-Reply-To: References: Message-ID: > Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: minor fixup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8887/files - new: https://git.openjdk.java.net/jdk/pull/8887/files/faab3ea1..c2cc3391 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8887.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8887/head:pull/8887 PR: https://git.openjdk.java.net/jdk/pull/8887 From clanger at openjdk.java.net Wed May 25 17:48:12 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 25 May 2022 17:48:12 GMT Subject: RFR: 8287336: GHA: Workflows break on patch versions Message-ID: This fixes the issue on GHA when the branch contains a patch version. Here you can see the problem: https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187 And here you see how it looks if it's fixed: https://github.com/RealCLanger/jdk18u/actions/runs/2384983103 I plan to backport this fix to 18u, where the problem currently occurs, immediately. ------------- Commit messages: - JDK-8287336 Changes: https://git.openjdk.java.net/jdk/pull/8888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8888&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287336 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8888/head:pull/8888 PR: https://git.openjdk.java.net/jdk/pull/8888 From shade at openjdk.java.net Wed May 25 17:53:31 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 May 2022 17:53:31 GMT Subject: RFR: 8287336: GHA: Workflows break on patch versions In-Reply-To: References: Message-ID: On Wed, 25 May 2022 17:17:12 GMT, Christoph Langer wrote: > This fixes the issue on GHA when the branch contains a patch version. > > Here you can see the problem: https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187 > And here you see how it looks if it's fixed: https://github.com/RealCLanger/jdk18u/actions/runs/2384983103 > > I plan to backport this fix to 18u, where the problem currently occurs, immediately. Ah yes. Looks good! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8888 From joehw at openjdk.java.net Wed May 25 20:47:42 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 25 May 2022 20:47:42 GMT Subject: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter [v2] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 17:15:18 GMT, Naoto Sato wrote: >> Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > minor fixup Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8887 From kbarrett at openjdk.java.net Thu May 26 04:03:54 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 26 May 2022 04:03:54 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:16:43 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Change Array::data() implementation > - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp Mostly good, but I missed a problem with an earlier part of the change. Sorry I didn't notice sooner. src/java.base/unix/native/libjli/java_md_common.c line 133: > 131: > 132: snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { That should be `||` rather than `&&`. src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { > 134: return 0; > 135: } Pre-existing: It seems odd that this returns `0` above and below, rather than returning `NULL`. I think there are one or two other places in this file that are similarly using literal `0` for a null pointer, though others are using `NULL`. Something to report and clean up separately from this change. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 26 10:55:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 26 May 2022 10:55:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v10] In-Reply-To: References: Message-ID: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/17cda224..851279ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 26 10:55:29 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 26 May 2022 10:55:29 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: <4B8Ib70PFV8uvUPrVUSiLk5560QAhHhUkJFpyyzUmRk=.c1f7b721-e51a-4e24-b8b3-a896bff7e1b4@github.com> On Thu, 26 May 2022 03:48:31 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change Array::data() implementation >> - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp > > src/java.base/unix/native/libjli/java_md_common.c line 133: > >> 131: >> 132: snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { > > That should be `||` rather than `&&`. Good catch! I fixed it in new commit. > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { >> 134: return 0; >> 135: } > > Pre-existing: It seems odd that this returns `0` above and below, rather than returning `NULL`. I think there are one or two other places in this file that are similarly using literal `0` for a null pointer, though others are using `NULL`. Something to report and clean up separately from this change. I was wondering about that too. I use `NULL` at L134, and have filed it as [JDK-8287363](https://bugs.openjdk.java.net/browse/JDK-8287363). I will work for it after this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ihse at openjdk.java.net Thu May 26 12:12:06 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 26 May 2022 12:12:06 GMT Subject: RFR: 8287366: Improve test failure reporting in GHA Message-ID: It is currently both tricky and tedious to figure out what went wrong when a jtreg test fails in GHA. We should utilize the full potential of GitHub Action summaries and error annotations to make finding failures easier and more discoverable. With this PR, the overview of failures are presented on the "Summary" page for the action (the top-most line to the left, with the outline house icon). Below the `submit.yml` dependency graph, you'll find the annotations, which will look like this: Linux x86 (jdk/tier1 part 1) Test run reported 34 test failure(s) and 0 error(s). See summary for details. Below the annotations follow the summaries. Go have a look at the runs for this PR to see what it looks like! In short, there is a separate summary per test job. The first part lists the names of the failed tests. This will always be included. Below this (with links from the summary list) are detailed information for each failed test. This include the jtreg output, and the `hs_err` file(s), if present. The latter part has a limit from Github on 1 MB. If this limit is broken, no detailed information at all is presented (sorry 'bout that; GitHub's rules). This PR is deliberately based on a commit prior to the fix for JDK-8287137 (Problemlist failing x86_32 tests after Loom integration), so you can see for yourself how the GHA runs looks in case of a "train wreck" testing situation, like on x86 after Loom. As you can see, most of the output part of the summaries got larger than the 1 MB limit, which means they were not shown. Only the summary for `Linux x86 (hs/tier1 runtime)` displays as intended. OTOH, this shows that the system has a "graceful degradation" mode for even large amount of failures like this. And, since I don't see a Loom v2.0 coming anytime soon, I believe this amount of failed tests are unlikely to be a realistic scenario. Finally: the duplication in submit.yml is really, really annoying. :-( I have copied the same code block to three places. The fourth place, for Windows, do not get any support at this time. Concurrently with this change, I have started a separate branch where I split up submit.yml into reusable parts, using "callable workflows" and "custom actions". As part of this effort, I will also change the windows jobs to use cygwin bash instead of PowerShell. Until then, I could not be bothered to even think about implementing this functionality in PS. When that change is integrated, Windows will get this functionality for free, too. ------------- Commit messages: - Extra commit to re-trigger the GHA - 8287366: Improve test failure reporting in GHA Changes: https://git.openjdk.java.net/jdk/pull/8901/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8901&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287366 Stats: 285 lines in 1 file changed: 264 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/8901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8901/head:pull/8901 PR: https://git.openjdk.java.net/jdk/pull/8901 From naoto at openjdk.java.net Thu May 26 15:55:41 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 26 May 2022 15:55:41 GMT Subject: Integrated: 8287187: Utilize HashMap.newHashMap() in CLDRConverter In-Reply-To: References: Message-ID: On Wed, 25 May 2022 16:43:59 GMT, Naoto Sato wrote: > Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones. This pull request has now been integrated. Changeset: c10749a6 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c10749a6a70977fbd6cd33b298410d212276fcf1 Stats: 65 lines in 1 file changed: 8 ins; 1 del; 56 mod 8287187: Utilize HashMap.newHashMap() in CLDRConverter Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/8887 From clanger at openjdk.java.net Thu May 26 15:58:46 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 26 May 2022 15:58:46 GMT Subject: RFR: 8287336: GHA: Workflows break on patch versions In-Reply-To: References: Message-ID: On Wed, 25 May 2022 17:50:29 GMT, Aleksey Shipilev wrote: >> This fixes the issue on GHA when the branch contains a patch version. >> >> Here you can see the problem: https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187 >> And here you see how it looks if it's fixed: https://github.com/RealCLanger/jdk18u/actions/runs/2384983103 >> >> I plan to backport this fix to 18u, where the problem currently occurs, immediately. > > Ah yes. Looks good! Thanks @shipilev for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8888 From clanger at openjdk.java.net Thu May 26 15:58:47 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 26 May 2022 15:58:47 GMT Subject: Integrated: 8287336: GHA: Workflows break on patch versions In-Reply-To: References: Message-ID: On Wed, 25 May 2022 17:17:12 GMT, Christoph Langer wrote: > This fixes the issue on GHA when the branch contains a patch version. > > Here you can see the problem: https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187 > And here you see how it looks if it's fixed: https://github.com/RealCLanger/jdk18u/actions/runs/2384983103 > > I plan to backport this fix to 18u, where the problem currently occurs, immediately. This pull request has now been integrated. Changeset: e44465d4 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/e44465d4d6eaddebfc5a1b149223aa8332affa8b Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8287336: GHA: Workflows break on patch versions Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8888 From clanger at openjdk.java.net Thu May 26 16:16:04 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 26 May 2022 16:16:04 GMT Subject: RFR: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows Message-ID: This fixes the Windows GHA test failures that popped up short time ago, e.g. [these](https://github.com/RealCLanger/jdk/runs/6598399845) Failing tests: tools/javac/Paths/MineField.sh tools/javac/Paths/wcMineField.sh I've debugged it and it comes down to calls to javac/java in the test through env are failing with RC 127. E.g. here: https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 Don't know why but I figured that the test failure goes away with current cygwin. It should be ok to update cygwin now because the bug that made JDK-8276854 necessary seems to be fixed. ------------- Commit messages: - JDK-8287378 Changes: https://git.openjdk.java.net/jdk/pull/8903/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8903&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287378 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8903.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8903/head:pull/8903 PR: https://git.openjdk.java.net/jdk/pull/8903 From kbarrett at openjdk.java.net Thu May 26 18:18:41 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 26 May 2022 18:18:41 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v10] In-Reply-To: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> References: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> Message-ID: On Thu, 26 May 2022 10:55:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From darcy at openjdk.java.net Thu May 26 22:37:15 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 22:37:15 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 Message-ID: Time to start getting ready for JDK 20... ------------- Commit messages: - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Update symbol information for JDK 19 b23. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/295be6f1...49c871d9 Changes: https://git.openjdk.java.net/jdk/pull/8236/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284858 Stats: 6210 lines in 67 files changed: 6166 ins; 0 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From darcy at openjdk.java.net Thu May 26 22:37:15 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 22:37:15 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... The expected kinds of updates to start up JDK 20. ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From dholmes at openjdk.java.net Thu May 26 22:46:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 22:46:42 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... One comment below. I ignored the sym files. Everything else appears okay. Thanks. src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312: > 310: int V18 = 0 << 16 | 62; > 311: int V19 = 0 << 16 | 63; > 312: int V20 = 0 << 17 | 64; 17 ?? Though why do we even bother with this when the minor version is zero? Simple assignment works. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8236 From kcr at openjdk.java.net Thu May 26 22:46:44 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 May 2022 22:46:44 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4): ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From darcy at openjdk.java.net Thu May 26 23:05:32 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 23:05:32 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: > Time to start getting ready for JDK 20... Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/49c871d9..96be1787 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From darcy at openjdk.java.net Thu May 26 23:05:33 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 23:05:33 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 26 May 2022 22:40:59 GMT, Kevin Rushforth wrote: > You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4): Acknowledged; will fix in the next push. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From darcy at openjdk.java.net Thu May 26 23:05:33 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 23:05:33 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 22:38:12 GMT, David Holmes wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312: > >> 310: int V18 = 0 << 16 | 62; >> 311: int V19 = 0 << 16 | 63; >> 312: int V20 = 0 << 17 | 64; > > 17 ?? > > Though why do we even bother with this when the minor version is zero? Simple assignment works. Doh! Will fix in the next pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From kcr at openjdk.java.net Thu May 26 23:28:36 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 May 2022 23:28:36 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From iris at openjdk.java.net Fri May 27 04:04:35 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 27 May 2022 04:04:35 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From clanger at openjdk.java.net Fri May 27 06:19:41 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 27 May 2022 06:19:41 GMT Subject: RFR: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows In-Reply-To: References: Message-ID: On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote: > This fixes the Windows GHA test failures that popped up short time ago, e.g. [these](https://github.com/RealCLanger/jdk/runs/6598399845) > > Failing tests: > tools/javac/Paths/MineField.sh > tools/javac/Paths/wcMineField.sh > > I've debugged it and it comes down to calls to javac/java in the test through env are failing with RC 127. E.g. here: > https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 > > Don't know why but I figured that the test failure goes away with current cygwin. > > It should be ok to update cygwin now because the bug that made JDK-8276854 necessary seems to be fixed. PS: The Windows langtools failure seen here is jdk/jshell/HighlightUITest.java, which seems to be unstable as of [JDK-8284144](https://bugs.openjdk.java.net/browse/JDK-8284144) and has already been excluded on several other platforms but not Windows yet. ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8903 From dholmes at openjdk.java.net Fri May 27 06:22:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 May 2022 06:22:36 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From erikj at openjdk.java.net Fri May 27 12:24:52 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 May 2022 12:24:52 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From thomas.stuefe at gmail.com Fri May 27 13:12:53 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 May 2022 15:12:53 +0200 Subject: gcc, arm, and thumbs mode Message-ID: Hi, I am investigating the arm-specific problem https://bugs.openjdk.java.net/browse/JDK-8283326. It looks like the error is caused by arm- and thumb-code interleaving: GCC-compiled code, in thumb mode, calls into a static assembler subroutine that has been compiled into arm mode, but the caller uses the wrong call instruction and we call into SafeFetch without switching into arm mode (gcc-generated code uses bl instead of blx). This problem only happens if the OpenJDK was built with a GCC that itself was built with --with-mode=thumb. Without that option, GCC defaults to arm code generation, and that hides the error I describe above. My question is: Is this by design? It seems strange to leave this decision up to whoever built the toolchain. Should we not fix the arm/thumb decision at build time with either one of -mthumb or -marm? Thanks, Thomas P.S. I found one possible solution for my particular problem was to add `.type function` to the static assembler routine. That caused gcc to use the correct jump instruction (blx instead of bl). But I am not sure this is the best solution, maybe best would be to just use the same mode for all hotspot compilation units. From thomas.stuefe at gmail.com Fri May 27 13:16:42 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 May 2022 15:16:42 +0200 Subject: gcc, arm, and thumbs mode In-Reply-To: References: Message-ID: (cited the wrong JBS issue, the correct one is https://bugs.openjdk.java.net/browse/JDK-8284997) On Fri, May 27, 2022 at 3:12 PM Thomas St?fe wrote: > Hi, > > I am investigating the arm-specific problem > https://bugs.openjdk.java.net/browse/JDK-8283326. It looks like the > error is caused by arm- and thumb-code interleaving: GCC-compiled code, in > thumb mode, calls into a static assembler subroutine that has been compiled > into arm mode, but the caller uses the wrong call instruction and we call > into SafeFetch without switching into arm mode (gcc-generated code uses bl > instead of blx). > > This problem only happens if the OpenJDK was built with a GCC that itself > was built with --with-mode=thumb. Without that option, GCC defaults to arm > code generation, and that hides the error I describe above. > > My question is: Is this by design? It seems strange to leave this decision > up to whoever built the toolchain. Should we not fix the arm/thumb decision > at build time with either one of -mthumb or -marm? > > Thanks, Thomas > > P.S. I found one possible solution for my particular problem was to add > `.type function` to the static assembler routine. That caused gcc to use > the correct jump instruction (blx instead of bl). But I am not sure this is > the best solution, maybe best would be to just use the same mode for all > hotspot compilation units. > From akozlov at azul.com Fri May 27 13:27:58 2022 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 27 May 2022 16:27:58 +0300 Subject: gcc, arm, and thumbs mode In-Reply-To: References: Message-ID: <249b2765-ccc3-01f9-61a0-a44e266812ec@azul.com> Hi Thomas, On 5/27/22 16:12, Thomas St?fe wrote: > P.S. I found one possible solution for my particular problem was to add > `.type function` to the static assembler routine. That caused gcc to use > the correct jump instruction (blx instead of bl). But I am not sure this is > the best solution, maybe best would be to just use the same mode for all > hotspot compilation units. AFAIR, that .type %function directive is a correct way to write asm code. At least this is what gcc generates for the C code [1]. I'm not sure how the annotation in the assembly code affects the caller code, may be link time optimization? But if adding the directive resolves the issue, I vote for it. (I expect arm-none crosscompiler to produce similar results compared to arm-linux target) Thanks, Anton $ echo "int main() { return 0; }" | arm-none-eabi-gcc -mthumb -S -x c - -o - .cpu arm7tdmi .arch armv4t .fpu softvfp .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .eabi_attribute 26, 1 .eabi_attribute 30, 6 .eabi_attribute 34, 0 .eabi_attribute 18, 4 .file "" .text .align 1 .global main .syntax unified .code 16 .thumb_func .type main, %function main: @ Function supports interworking. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 1, uses_anonymous_args = 0 push {r7, lr} add r7, sp, #0 movs r3, #0 movs r0, r3 mov sp, r7 @ sp needed pop {r7} pop {r1} bx r1 .size main, .-main .ident "GCC: (Arch Repository) 12.1.0" From iris at openjdk.java.net Fri May 27 17:50:46 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 27 May 2022 17:50:46 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From ysuenaga at openjdk.java.net Sat May 28 02:12:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 28 May 2022 02:12:43 GMT Subject: Integrated: 8286562: GCC 12 reports some compiler warnings In-Reply-To: References: Message-ID: On Wed, 11 May 2022 05:58:31 GMT, Yasumasa Suenaga wrote: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: This pull request has now been integrated. Changeset: 410a25d5 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464 Stats: 41 lines in 5 files changed: 26 ins; 1 del; 14 mod 8286562: GCC 12 reports some compiler warnings Reviewed-by: ihse, kbarrett, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From david.holmes at oracle.com Sat May 28 05:44:41 2022 From: david.holmes at oracle.com (David Holmes) Date: Sat, 28 May 2022 15:44:41 +1000 Subject: Integrated: 8286562: GCC 12 reports some compiler warnings In-Reply-To: References: Message-ID: The new assertion in src/hotspot/share/utilities/globalDefinitions.hpp inline const char* type2name(BasicType t) { assert((uint)t < T_CONFLICT + 1, "invalid type"); return type2name_tab[t]; } is failing with test compiler/jvmci/errors/TestInvalidDebugInfo.java I have filed: https://bugs.openjdk.java.net/browse/JDK-8287491 The test will probably need ProblemListing as it is causing major noise in our CI. David On 28/05/2022 12:12 pm, Yasumasa Suenaga wrote: > On Wed, 11 May 2022 05:58:31 GMT, Yasumasa Suenaga wrote: > >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > This pull request has now been integrated. > > Changeset: 410a25d5 > Author: Yasumasa Suenaga > URL: https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464 > Stats: 41 lines in 5 files changed: 26 ins; 1 del; 14 mod > > 8286562: GCC 12 reports some compiler warnings > > Reviewed-by: ihse, kbarrett, prr > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/8646 From duke at openjdk.java.net Sat May 28 11:56:23 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Sat, 28 May 2022 11:56:23 GMT Subject: RFR: 8287171: Refactor null caller tests to a single directory Message-ID: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports. ------------- Commit messages: - 8287171: Refactor null caller tests to a single directory Changes: https://git.openjdk.java.net/jdk/pull/8934/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287171 Stats: 1293 lines in 18 files changed: 511 ins; 780 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934 PR: https://git.openjdk.java.net/jdk/pull/8934 From clanger at openjdk.java.net Sun May 29 12:57:44 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Sun, 29 May 2022 12:57:44 GMT Subject: RFR: 8287366: Improve test failure reporting in GHA In-Reply-To: References: Message-ID: On Thu, 26 May 2022 12:04:41 GMT, Magnus Ihse Bursie wrote: > It is currently both tricky and tedious to figure out what went wrong when a jtreg test fails in GHA. > > We should utilize the full potential of GitHub Action summaries and error annotations to make finding failures easier and more discoverable. > > With this PR, the overview of failures are presented on the "Summary" page for the action (the top-most line to the left, with the outline house icon). Below the `submit.yml` dependency graph, you'll find the annotations, which will look like this: > > > Linux x86 (jdk/tier1 part 1) > Test run reported 34 test failure(s) and 0 error(s). See summary for details. > > > Below the annotations follow the summaries. Go have a look at the runs for this PR to see what it looks like! In short, there is a separate summary per test job. The first part lists the names of the failed tests. This will always be included. Below this (with links from the summary list) are detailed information for each failed test. This include the jtreg output, and the `hs_err` file(s), if present. The latter part has a limit from Github on 1 MB. If this limit is broken, no detailed information at all is presented (sorry 'bout that; GitHub's rules). > > This PR is deliberately based on a commit prior to the fix for JDK-8287137 (Problemlist failing x86_32 tests after Loom integration), so you can see for yourself how the GHA runs looks in case of a "train wreck" testing situation, like on x86 after Loom. As you can see, most of the output part of the summaries got larger than the 1 MB limit, which means they were not shown. Only the summary for `Linux x86 (hs/tier1 runtime)` displays as intended. OTOH, this shows that the system has a "graceful degradation" mode for even large amount of failures like this. And, since I don't see a Loom v2.0 coming anytime soon, I believe this amount of failed tests are unlikely to be a realistic scenario. > > Finally: the duplication in submit.yml is really, really annoying. :-( I have copied the same code block to three places. The fourth place, for Windows, do not get any support at this time. Concurrently with this change, I have started a separate branch where I split up submit.yml into reusable parts, using "callable workflows" and "custom actions". As part of this effort, I will also change the windows jobs to use cygwin bash instead of PowerShell. Until then, I could not be bothered to even think about implementing this functionality in PS. When that change is integrated, Windows will get this functionality for free, too. This is a great improvement to GHA. I'm also looking forward to your de-duplication efforts and basing the windows steps on cygwin to benefit from the error handling there as well. Thanks for doing this! ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8901 From duke at openjdk.java.net Sun May 29 16:44:40 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Sun, 29 May 2022 16:44:40 GMT Subject: RFR: 8287171: Refactor null caller tests to a single directory [v2] In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> Message-ID: > Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports. Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8287171 - 8287171: Refactor null caller tests to a single directory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8934/files - new: https://git.openjdk.java.net/jdk/pull/8934/files/5eba965b..a54aa747 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=00-01 Stats: 2803 lines in 65 files changed: 1631 ins; 617 del; 555 mod Patch: https://git.openjdk.java.net/jdk/pull/8934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934 PR: https://git.openjdk.java.net/jdk/pull/8934 From duke at openjdk.java.net Mon May 30 00:10:50 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Mon, 30 May 2022 00:10:50 GMT Subject: RFR: 8287171: Refactor null caller tests to a single directory [v3] In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> Message-ID: > Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: problem with iostream on Windows, use printf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8934/files - new: https://git.openjdk.java.net/jdk/pull/8934/files/a54aa747..f1406a45 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=01-02 Stats: 14 lines in 2 files changed: 8 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934 PR: https://git.openjdk.java.net/jdk/pull/8934 From alanb at openjdk.java.net Mon May 30 05:40:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 30 May 2022 05:40:40 GMT Subject: RFR: 8287171: Refactor null caller tests to a single directory [v3] In-Reply-To: References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> Message-ID: On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing wrote: >> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > problem with iostream on Windows, use printf I don't think jdk/nullCaller is right location for this. Maybe jni/nullCaller could work. You'll probably need to add the location to an appropriate group/tier in test/jdk/TEST.groups, otherwise it won't be run. ------------- PR: https://git.openjdk.java.net/jdk/pull/8934 From thomas.stuefe at gmail.com Mon May 30 05:57:01 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 30 May 2022 07:57:01 +0200 Subject: gcc, arm, and thumbs mode In-Reply-To: <249b2765-ccc3-01f9-61a0-a44e266812ec@azul.com> References: <249b2765-ccc3-01f9-61a0-a44e266812ec@azul.com> Message-ID: Hi Anton, thanks for looking into this. For my specific problem, I can and probably should use .function. But my question was more general, should we leave the decision whether to use thumb or arm up to the toolchain. For two reasons, one is executable size - I assume using thumb has certain advantages, executables are smaller and you can fit more into the instruction cache, and second, because errors like mine are probably not that uncommon and it makes me nervous that we only caught it because someone happened to build on his Raspi. Cheers, Thomas On Fri, May 27, 2022 at 3:28 PM Anton Kozlov wrote: > Hi Thomas, > > On 5/27/22 16:12, Thomas St?fe wrote: > > P.S. I found one possible solution for my particular problem was to add > > `.type function` to the static assembler routine. That caused gcc to use > > the correct jump instruction (blx instead of bl). But I am not sure this > is > > the best solution, maybe best would be to just use the same mode for all > > hotspot compilation units. > > AFAIR, that .type %function directive is a correct way to write asm > code. At least this is what gcc generates for the C code [1]. I'm not > sure how the annotation in the assembly code affects the caller code, > may be link time optimization? But if adding the directive resolves the > issue, I vote for it. > > (I expect arm-none crosscompiler to produce similar results compared to > arm-linux target) > > Thanks, > Anton > > $ echo "int main() { return 0; }" | arm-none-eabi-gcc -mthumb -S -x c - -o > - > .cpu arm7tdmi > .arch armv4t > .fpu softvfp > .eabi_attribute 20, 1 > .eabi_attribute 21, 1 > .eabi_attribute 23, 3 > .eabi_attribute 24, 1 > .eabi_attribute 25, 1 > .eabi_attribute 26, 1 > .eabi_attribute 30, 6 > .eabi_attribute 34, 0 > .eabi_attribute 18, 4 > .file "" > .text > .align 1 > .global main > .syntax unified > .code 16 > .thumb_func > .type main, %function > main: > @ Function supports interworking. > @ args = 0, pretend = 0, frame = 0 > @ frame_needed = 1, uses_anonymous_args = 0 > push {r7, lr} > add r7, sp, #0 > movs r3, #0 > movs r0, r3 > mov sp, r7 > @ sp needed > pop {r7} > pop {r1} > bx r1 > .size main, .-main > .ident "GCC: (Arch Repository) 12.1.0" > > From aturbanov at openjdk.java.net Mon May 30 06:23:42 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 30 May 2022 06:23:42 GMT Subject: RFR: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows In-Reply-To: References: Message-ID: On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote: > This fixes the Windows GHA test failures that popped up short time ago, e.g. [these](https://github.com/RealCLanger/jdk/runs/6598399845) > > Failing tests: > tools/javac/Paths/MineField.sh > tools/javac/Paths/wcMineField.sh > > I've debugged it and it comes down to calls to javac/java in the test through env are failing with RC 127. E.g. here: > https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 > > Don't know why but I figured that the test failure goes away with current cygwin. > > It should be ok to update cygwin now because the bug that made JDK-8276854 necessary seems to be fixed. Marked as reviewed by aturbanov (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8903 From aph-open at littlepinkcloud.com Mon May 30 08:42:22 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 30 May 2022 09:42:22 +0100 Subject: gcc, arm, and thumbs mode In-Reply-To: References: <249b2765-ccc3-01f9-61a0-a44e266812ec@azul.com> Message-ID: On 5/30/22 06:57, Thomas St?fe wrote: > For my specific problem, I can and probably should use .function. But my > question was more general, should we leave the decision whether to use > thumb or arm up to the toolchain. For two reasons, one is executable size - > I assume using thumb has certain advantages, executables are smaller and > you can fit more into the instruction cache, and second, because errors > like mine are probably not that uncommon and it makes me nervous that we > only caught it because someone happened to build on his Raspi. Indeed! I'm surprised the problem doesn't come up in other places too. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ihse at openjdk.java.net Mon May 30 09:26:31 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 30 May 2022 09:26:31 GMT Subject: RFR: 8287171: Refactor null caller tests to a single directory [v3] In-Reply-To: References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> Message-ID: On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing wrote: >> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > problem with iostream on Windows, use printf Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8934 From clanger at openjdk.java.net Mon May 30 14:50:36 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 30 May 2022 14:50:36 GMT Subject: RFR: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows In-Reply-To: References: Message-ID: On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote: > This fixes the Windows GHA test failures that popped up short time ago, e.g. [these](https://github.com/RealCLanger/jdk/runs/6598399845) > > Failing tests: > tools/javac/Paths/MineField.sh > tools/javac/Paths/wcMineField.sh > > I've debugged it and it comes down to calls to javac/java in the test through env are failing with RC 127. E.g. here: > https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 > > Don't know why but I figured that the test failure goes away with current cygwin. > > It should be ok to update cygwin now because the bug that made JDK-8276854 necessary seems to be fixed. @magicus @shipilev, WDYT? I would like to backport this to get GHA results greener... ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8903 From shade at openjdk.java.net Mon May 30 14:54:45 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 May 2022 14:54:45 GMT Subject: RFR: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows In-Reply-To: References: Message-ID: On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote: > This fixes the Windows GHA test failures that popped up short time ago, e.g. [these](https://github.com/RealCLanger/jdk/runs/6598399845) > > Failing tests: > tools/javac/Paths/MineField.sh > tools/javac/Paths/wcMineField.sh > > I've debugged it and it comes down to calls to javac/java in the test through env are failing with RC 127. E.g. here: > https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 > > Don't know why but I figured that the test failure goes away with current cygwin. > > It should be ok to update cygwin now because the bug that made JDK-8276854 necessary seems to be fixed. Ah, Cygwin again. Current patch looks fine. Given how nasty Cygwin-caused failures are, I think keeping the version nailed still makes sense. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8903 From clanger at openjdk.java.net Mon May 30 15:02:49 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 30 May 2022 15:02:49 GMT Subject: RFR: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows In-Reply-To: References: Message-ID: On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote: > This fixes the Windows GHA test failures that popped up short time ago, e.g. [these](https://github.com/RealCLanger/jdk/runs/6598399845) > > Failing tests: > tools/javac/Paths/MineField.sh > tools/javac/Paths/wcMineField.sh > > I've debugged it and it comes down to calls to javac/java in the test through env are failing with RC 127. E.g. here: > https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 > > Don't know why but I figured that the test failure goes away with current cygwin. > > It should be ok to update cygwin now because the bug that made JDK-8276854 necessary seems to be fixed. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8903 From clanger at openjdk.java.net Mon May 30 15:02:50 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 30 May 2022 15:02:50 GMT Subject: Integrated: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows In-Reply-To: References: Message-ID: On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote: > This fixes the Windows GHA test failures that popped up short time ago, e.g. [these](https://github.com/RealCLanger/jdk/runs/6598399845) > > Failing tests: > tools/javac/Paths/MineField.sh > tools/javac/Paths/wcMineField.sh > > I've debugged it and it comes down to calls to javac/java in the test through env are failing with RC 127. E.g. here: > https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 > > Don't know why but I figured that the test failure goes away with current cygwin. > > It should be ok to update cygwin now because the bug that made JDK-8276854 necessary seems to be fixed. This pull request has now been integrated. Changeset: f086d945 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/f086d945c31d3673e0a49017e3d4e99b189253fe Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows Reviewed-by: aturbanov, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8903 From mchung at openjdk.java.net Tue May 31 18:02:41 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 May 2022 18:02:41 GMT Subject: RFR: 8287171: Refactor null caller tests to a single directory [v3] In-Reply-To: References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> Message-ID: <-pz5TC_Wwx7eDI2EPJY5NFP0migvoMHt8um2zaNR18E=.88720eb9-5b0e-4673-94d0-8c97de543ebc@github.com> On Mon, 30 May 2022 05:37:16 GMT, Alan Bateman wrote: > I don't think jdk/nullCaller is right location for this. Maybe jni/nullCaller could work. You'll probably need to add the location to an appropriate group/tier in test/jdk/TEST.groups, otherwise it won't be run. I also think `test/jdk/jni/nullCaller` is better. ------------- PR: https://git.openjdk.java.net/jdk/pull/8934 From mchung at openjdk.java.net Tue May 31 18:02:45 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 May 2022 18:02:45 GMT Subject: RFR: 8287171: Refactor null caller tests to a single directory [v3] In-Reply-To: References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com> Message-ID: On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing wrote: >> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > problem with iostream on Windows, use printf test/jdk/jdk/nullCaller/CallHelper.hpp line 176: > 174: } > 175: > 176: // call an method returning an object checking for exceptions and `s/an method/a method/` test/jdk/jdk/nullCaller/exeNullCallerTest.cpp line 29: > 27: * ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame > 28: */ > 29: void JDK_8280902(JNIEnv* env) { A descriptive method name would be more helpful than the bug ID, for example, `getResourceBundle` and `registerClassLoaderAsParallelCapable` test/jdk/jdk/nullCaller/exeNullCallerTest.cpp line 49: > 47: > 48: // check the message > 49: if (std::string("Hello!") != env->GetStringUTFChars(msg,NULL)) { nit: a space after the comma `(msg, NULL)` consistent with the format in this local file. ------------- PR: https://git.openjdk.java.net/jdk/pull/8934 From darcy at openjdk.java.net Tue May 31 20:32:13 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 31 May 2022 20:32:13 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3] In-Reply-To: References: Message-ID: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com> > Time to start getting ready for JDK 20... Joe Darcy 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 36 additional commits since the last revision: - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - Respond to review feedback. - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Update symbol information for JDK 19 b23. - ... and 26 more: https://git.openjdk.java.net/jdk/compare/57d97d36...eedd36bd ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/96be1787..eedd36bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=01-02 Stats: 41686 lines in 344 files changed: 18832 ins; 17644 del; 5210 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From iris at openjdk.java.net Tue May 31 21:47:40 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 31 May 2022 21:47:40 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3] In-Reply-To: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com> References: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com> Message-ID: On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy 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 36 additional commits since the last revision: > > - Update deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Respond to review feedback. > - Update symbol information for JDK 19 b24. > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Update symbol information for JDK 19 b23. > - ... and 26 more: https://git.openjdk.java.net/jdk/compare/d01d01b5...eedd36bd Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236